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Abstract 


Case  Studies  in  Downsizing  is  the  third  in  a  series  of  issue  reports  pub- 
lished by  INPUT  that  examine  current  downsizing  trends.  It  presents,  in 
depth,  the  cases  of  five  organizations  that  have  akeady  downsized  or  are 
currently  doing  so.  The  report  also  discusses  several  downsizing  efforts 
that  have  been  published  in  the  trade  press.  The  purpose  of  this  report  is 
to  explore,  by  offering  real- world  examples,  the  reasons  for  and  effects  of 
downsizing  in  a  variety  of  institutions.  Is  downsizing  something  all 
companies  should  consider?  Is  it  the  right  approach  for  everyone?  Are 
companies  that  are  downsizing  achieving  the  benefits  they  expected? 
When  is  the  right  time  and  what  are  the  appropriate  conditions  for  down- 
sizing? Are  most  efforts  successful?  These  are  the  types  of  questions 
many  organizations  are  asking.  The  case  studies  presented  in  this  report 
are  intended  to  help  answer  such  questions. 

The  types  of  organizations  included — in  both  the  in-depth  and  review 
sections — are  diverse.  The  range  spans  a  major  university,  a  railroad,  a 
minicomputer  company,  a  utility,  a  large  furniture  chain,  and  a  county 
government,  to  name  a  few.  From  this  broad  spectrum  of  cases,  and 
careful  examination  of  the  problems  and  successes  of  their  downsizing 
endeavors,  INPUT  hopes  to  clarify  matters  for  companies  in  search  of  a 
downsizing  solution. 

The  report  contains  132  pages,  23  exhibits,  and  a  bibliography. 
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Introduction 


INPUT  has  been  concerned  about  the  economics  of  computer-communica- 
tions networks  since  the  company  was  formed  over  15  years  ago.  In  the 
mid-1970s,  INPUT  conducted  extensive  research  that  verified  classic 
economy  of  scale  within  the  IBM  product  line,  and  clearly  demonstrated 
the  advantages  of  replacing  standalone  systems  with  a  hierarchical  net- 
work based  on  large,  host  mainframes.  It  was  determined  that  these  large 
mainframes  replaced  more  standalone  systems  than  was  indicated  by 
simple  price/performance  ratios,  and  INPUT  published  tables  of  "replace- 
ment ratios"  to  guide  clients  who  wanted  to  take  advantage  of  the  "new 
hardware  economics." 

In  addition,  it  became  apparent  that  reduced  hardware  expense  was  only 
one  of  numerous  benefits  of  large  data  centers.  The  arguments  for  (and 
economics  oO  consolidation  of  processing,  data  and  human  resources  at 
that  time  were  compelling;  and  many  of  them  were  independent  of  hard- 
ware price/performance.  However,  INPUT  was  fully  aware  that  both 
minicomputers  and  microprocessor-based  "inteUigent  terminals"  were  on 
much  steeper  price/performance  curves  than  were  mainframes.  For  that 
reason,  INPUT  recommended  a  strategy  of  consolidation  followed  by  the 
"orderly  distribution  of  processing"  back  to  user  departments. 

At  the  beginning  of  INPUT'S  research  on  downsizing,  it  was  apparent  that 
the  diffusion  of  microprocessor-based  technology  during  the  1980s  was 
not  an  orderly  process,  and  that  downsizing  was  being  promoted  as  an 
extension  of  the  personal  computer  "revolution"  with  little  regard  for 
proper  network  structure.  The  myopic  focus  on  MIPS  seemed  to  ignore 
both  the  benefits  of  centralization  and  the  potential  problems  of  downsiz- 
ing. 

input's  initial  research  on  downsizing  tended  to  confirm  that  downsizing 
was  being  pursued  without  full  understanding  of  the  potential  conse- 
quences. Specifically: 
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•  The  primary  motivation  for  downsizing  was  found  to  be  the  reduction  of 
IS  and  hardware  costs,  but  those  who  had  completed  downsizing  efforts 
(or  who  were  about  to  complete  them)  no  longer  listed  cost  savings  as 
being  a  primary  anticipated  benefit. 

•  Published  industry  case  studies  of  completed  projects  also  waved  some 
red  flags  about  the  economics  of  downsizing  efforts.  For  example,  one 
company  broke  up  the  central  IS  function  and  then  found  that  it  had  to 
hire  a  comparable  number  of  IS  personnel  at  the  network  nodes,  and 
these  employees  were  more  expensive  because  higher  level  skills  were 
required  in  the  downsizing  environment. 

•  Technological  downsizing  is  being  accompanied  by  management  down- 
sizing (specifically,  reduction  in  levels  of  middle  management),  which 
probably  will  require  more  (rather  than  less)  investment  in  information 
technology. 

•  The  complexity  of  emerging  networks  of  systems  will  be  greater  than 
the  centralized  systems  being  replaced,  and  this  will  require  more  (not 
fewer)  professional  systems  personnel.  This  fact  is  being  ignored  by 
those  who  propose  "bottom-up  system  development,"  which  emphasizes 
turning  over  systems  development  responsibilities  to  casual  end  users. 

•  In  addition,  the  advocates  of  bottom-up  system  development  have 
adopted  a  client/server  architecture  based  on  the  assumption  that  a 
source  of  high-quality  data  will  be  available  somewhere  in  the  organiza- 
tion, and  that  the  potential  problems  of  distributed  data  base  manage- 
ment will  be  magically  solved  as  downsizing  proceeds. 

•  Finally,  the  published  literature  on  downsizing  shows  that  there  is  a  lot 
of  cream- skimming  going  on  in  current  downsizing  efforts.  Relatively 
simple  applications  and  functions  are  being  downsized,  and  all  of  the 
complexity  is  being  left  up  to  the  central  IS  organization.  While  there 
isn't  anything  inherently  wrong  with  cream- skimming,  there  is  substan- 
tial risk  that  the  central  data  center  will  be  exposed  to  declining  "in- 
come" with  little  possibility  of  reduced  expenses. 

INPUT  feels  it  is  important  to  understand  the  real  economics  of  computer- 
communications  networks  in  order  to  make  effective  use  of  new  informa- 
tion technology.  This  requires  identification  and  analysis  of  the  cost 
factors  related  to  downsizing.  INPUT  believes  this  can  only  be  accom- 
plished by  drawing  on  the  knowledge  of  those  who  are  developing  com- 
prehensive, long-range  plans  for  downsizing  current  networks.  Therefore, 
INPUT  has  carefully  selected  five  organizations  for  in-depth  cases  studies. 
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A  

Objectives 

This  report  has  the  following  objectives: 

•  To  review  briefly  the  economics  of  centralization  and  "upsizing"  in 
order  to  identify  benefits  that  may  be  overlooked,  and  perhaps  negated, 
by  indiscriminate  downsizing 

•  To  analyze  the  complex,  and  sometimes  conflicting,  motives  and  antici- 
pated benefits  of  downsizing 

•  To  separate  networking  knowledge  and  experience  from  the  information, 
propaganda  and  hype  that  have  become  attached  to  downsizing 

•  To  identify  the  benefits  and  problems  that  knowledgeable  people  antici- 
pate from  downsizing 

•  To  determine  how  innovative  information  technology  will  be  managed 
in  the  1990s 

•  To  review  the  current  state  of  planning  for  the  distribution  of  processing 
power  and  data  to  the  technological  and  organizational  hierarchies 

•  To  determine  the  andcipated  redistribution  of  responsibilities  for  the 
development  and  maintenance  of  information  systems  resources  (includ- 
ing data)  as  downsizing  proceeds 

•  To  idenufy  and  analyze  the  various  cost  factors  associated  with  down- 
sizing 

•  To  provide  a  general  framework  for  cost/benefit  analysis  of  downsizing 

•  To  summarize  and  synthesize  the  experience  and  knowledge  gained 
from  the  case  study  organizations 

•  To  make  recommendations  based  upon  the  synthesis  of  this  experience 
and  knowledge 
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B  

Methodology  and  Scope 

1.  Methodology 

INPUT  has  already  conducted  comprehensive  research  on  downsizing  in 
order  to  put  it  into  perspective.  The  data  obtained  from  that  research  has 
been  analyzed  from  an  architectural  point  of  view.  Based  on  this  research 
and  analysis,  INPUT  identified  certain  issues,  reached  some  conclusions, 
and  made  recommendations.  In  order  to  check  the  credibility  of  INPUT'S 
analysis,  and  extend  the  research  to  a  more  detailed  level,  five  organiza- 
tions were  selected  for  in-depth  strategic  analysis. 

These  organizations  have  not  been  selected  randomly.  They  have  been 
carefully  selected  based  on  the  experience  and  knowledge  of  their  IS 
executives.  Specifically,  INPUT  selected  organizations  (and  executives) 
that  have  experienced  cycles  of  centralization  and  decentralization,  and 
have  had  the  opportunity  (and  challenge)  of  developing  and  managing 
networks  of  systems  in  both  highly  centralized  and  distributed  environ- 
ments. Most  of  these  organizations  have  been  the  subject  of  detailed 
INPUT  research  in  the  past.  This  knowledge  base  provides  the  foundation 
for  putting  their  current  downsizing  innovations  into  proper  perspective. 
In  addition,  special  attention  was  given  to  selecting  diverse  organizational 
cultures,  because  it  is  INPUT'S  belief  that  the  success  of  both  technologi- 
cal and  management  downsizing  efforts  will  be  heavily  dependent  upon 
changes  in  mindset  and  organizational  culture. 

The  current  research  employed  multiple  personal  and  telephone  interviews 
with  the  case  study  companies.  These  interviews  were  designed  to  obtain 
information  concerning  the  issues  outlined  above.  The  focus  of  the  inter- 
views was  on  the  organizations'  strategic  plans  for  both  technological  and 
management  downsizing  with  emphasis  upon  cost/benefit  analysis.  Ap- 
proximately thirty-five  separate  interviewing  sessions  were  conducted. 

In  addition,  an  analysis  was  made  of  pubUshed  case  studies  over  a  three- 
month  period.  The  purpose  was  to  identify  actual  replacement  patterns  for 
various  platforms  and  the  benefits  anticipated  or  actually  achieved. 

2.  Scope 

The  scope  of  this  study  is  sufficient  to  provide  a  general  cost/benefit 
framework  for  planning  technological  downsizing  efforts,  and  provide 
"red  flags"  for  many  anticipated  problem  areas.  It  also  provides  a  set  of 
diverse  cultural  models  that  can  serve  as  points  of  reference  in  putting 
management  downsizing  into  perspective.  This  study  makes  no  pretense 
of  providing  a  "cookbook"  solution  for  either  technological  or  manage- 
ment downsizing,  but  it  should  be  a  useful  document  for  planning  pur- 
poses. 
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Report  Structure 

A  brief  description  of  the  report  is  as  follows: 

•  Chapter  n,  Executive  Overview,  provides  a  brief  summary  of  the  issues 
as  seen  by  the  case  study  organizations,  and  INPUT'S  conclusions  and 
recommendations  conceming  cost/benefit  analysis  of  downsizing. 

•  Chapter  HI,  Review  of  Previous  Research,  provides  a  succinct  review  of 
input's  previous  downsizing  research,  and  defines  the  major  issues 
that  have  been  identified. 

•  Chapter  IV,  Strategic  Case  Studies,  will  present  each  case  study  in  the 
following  format: 

-  Background  of  the  factors  prompting  downsizing,  application  selec- 
tion, architecture  selection  and  cost  justification 

-  Implementation  plans  in  terms  of  organization,  project  management 
and  support 

-  The  quantitative  and  qualitative  results  achieved  or  anticipated  for 
downsizing  in  the  following  areas: 

•  Application  Support 

•  Hardware 

•  Systems  Support 

•  Staffing 

•  Transition  Costs 

-  The  benefits  and/or  consequences  that  have  been  achieved  and/or  are 
anticipated  from  the  downsizing  effort 

•  Chapter  V,  Published  Case  Studies,  will  analyze  the  results  anticipated 
or  actually  achieved  in  published  case  studies. 

•  Chapter  VI,  Analysis  of  Case  Studies,  will  analyze  the  results  of  the 
research  in  the  case  study  format  presented  above. 

•  Chapter  VII,  Conclusions  and  Recommendations,  will  summarize 
input's  conclusions  and  recommendations  conceming  downsizing, 
with  emphasis  on  the  development  of  a  downsizing  strategy. 
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Executive  Overview 


Downsizing  is  a  media  event — a  modem  day,  technological  version  of 
David's  challenge  to  Goliath  played  out  and  reported  at  many  levels. 
Little  microprocessors  will  replace  mighty  mainframes  with  enormous 
savings  in  hardware  costs.  A  simple  "open"  operating  system  will  replace 
complex  proprietary  systems.  Cheap  shrink-wrapped  software  purchased 
off  the  shelf  will  make  massive  internal  development  efforts  unnecessary. 
End  users  employing  new  methodologies  and  tools  will  eliminate  the  need 
for  the  big  IS  department  with  its  systems  analysts  and  programmers.  A 
few  executives,  armed  with  new  information  technology,  will  slay  corpo- 
rate bureaucracy  and  reign  supreme  over  leaner,  meaner  organizations 
sans  layers  of  unnecessary  middle  management.  And  relatively  small, 
upstart  companies  will  finally  bring  IBM  to  its  knees  even  at  it  tries  to 
become  leaner  and  meaner  itself. 

That  is  how  the  story  goes,  and  both  the  media  and  corporate  executives 
want  to  believe  that  it  is  true.  The  media  is  merely  supporting  its  advertis- 
ers with  "news,"  but  corporate  executives  need  technological  downsizing 
to  support  their  own  organizational  downsizing  initiatives. 

IS  management,  for  obvious  reasons,  isn't  very  enthusiastic  about  some  of 
the  ramifications  of  downsizing.  While  the  media  reports  the  demise  of 
CIOs  who  have  "worked  themselves  out  of  a  job,"  those  who  remain  are 
confronted  with  major  challenges  in  achieving  the  anticipated  benefits  of 
downsizing  after  having  been  clearly  identified  as  being  part  of  the  prob- 
lem. IS  management,  in  turn,  has  identified  IBM  as  part  of  its  problem  for 
the  following  reasons: 

•  After  years  of  following  IBM  leadership  because  this  route  was  "safe,"  it 
has  been  found  to  lead  to  a  mainframe  trap — a  position  that  is  indefen- 
sible in  terms  of  cost  and  complexity. 

•  IBM's  plan  for  getting  out  of  the  mainframe  trap  (SAA)  has  not  been 
implemented  in  a  timely  manner,  appears  to  lack  definition  and  support 
within  IBM,  and  has  only  contributed  to  the  current  confusion  concern- 
ing downsizing. 
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•  Essentially,  customers  have  lost  confidence  in  IBM's  ability  to  "make  it 
work,"  and  the  result  is  loss  of  account  control 


A  

Summary  of  Strategic  Case  Studies 

1.  Case  Study  #1 

Case  study  #1  is  a  major  university  that  has  been  on  the  leading  edge  in 
the  application  of  information  technology.  It  is  now  trying  to  define  a 
long-range  information  architecture  based  on  downsizing  and  client/ 
server  architecture.  One  of  the  primary  cost  justifications  is  that  "off- 
the-shelf  software  (including  systems  software)  will  be  substituted  for 
in-house  development  and  maintenance. 

When  asked  about  the  analysis  underlying  the  decision  to  pursue  a  new 
information  architecture,  it  was  stated  that  it  was  "based  mosdy  on  what 
people  read  in  the  trade  press."  However,  part  of  the  planning  process 
involved  the  establishment  of  a  "Cost  and  Funding  Task  Force,"  which 
developed  the  comprehensive  cost  matrix  that  has  been  employed  in  this 
f        study.  Tentative  conclusions  are: 

•  There  will  be  at  least  two  more  major  upgrades  before  mainframe 
growth  can  be  contained. 

•  Some  of  the  cost/benefit  assumptions,  such  as  the  cost  benefits  associ- 
ated with  off-the-shelf  software,  are  being  questioned. 

•  While  it  is  possible  to  come  up  with  reasonably  good  estimates  of 
whether  certain  cells  in  the  cost  matrix  will  increase  or  decrease,  the  net 
impact  is  difficult  to  determine. 

•  It  has  already  been  concluded  that  the  transition  costs  for  specific  appli- 
cations could  never  be  recovered,  and  no  effort  will  be  made  to  convert 
such  applications  unless  there  is  a  good  business  reason. 

•  The  suspicion  is  that  the  net  effect  will  be  additional  investment  in 
information  technology.  Although  this  is  not  considered  necessarily 
bad,  it  is  suspected  that  this  is  not  what  management  has  in  mind — 
especially  in  the  short  term. 

2.  Case  Study  #2 

Case  Study  #2  is  a  major  railroad  that  has  done  everything  "right,"  but 
still  finds  itself  in  a  mainframe  trap. 
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•  At  one  point,  it  developed  all  of  its  own  software  (including  systems 
software),  but  it  then  opted  for  vendor-provided  software  because  it  was 
"free."  It  now  spends  $3  million  on  outside  software,  and  management 
is  wondering  how  it  ever  got  itself  in  its  current  position. 

•  It  adopted  COBOL  early  when  it  was  supposed  to  provide  ease  of  use, 
self-documentation,  and  portability  across  various  vendor  platforms. 
The  company  was  confident  that  COBOL  would  remain  the  common 
business  language  because  the  government  was  forcing  all  vendors  to 
support  COBOL.  It  now  finds  itself  with  a  thirty-year  investment  in 
COBOL  programming  that  is  a  most  serious  impediment  to  downsizing 
and  "open  systems." 

•  It  distributed  processing  in  the  1970s,  and  installed  a  large  minicomputer 
network,  only  to  find  that  its  mainframe  installation  continued  to  grow. 

•  It  has  been  a  pioneer  in  computer-communication  networks,  but  has 
been  forced  to  go  through  repeated  cycles  of  centralization  and  decen- 
tralization in  its  attempts  to  maintain  data  quality. 

•  One  application  that  has  been  downsized  to  RISC  workstations  is  the 
distribution  of  railroad  rolling  stock.  However,  the  supporting  data 
remains  on  the  mainframe,  and  despite  years  of  applying  the  latest 
techniques  of  both  operations  research  and  artificial  intelligence,  it  still 
isn't  "one  of  our  better  applications."  Cheap  processing  power  alone 
doesn't  always  solve  problems. 

The  railroad  has  literally  done  many  things  right  over  the  years,  and  it  has 
remained  on  the  leading  edge  in  the  effective  application  of  information 
technology.  The  number  of  employees  on  the  railroad  has  been  reduced 
substantially  in  the  last  ten  years  through  the  use  of  information  technol- 
ogy. Today,  an  image  processing  system  is  being  installed  that  will  lead 
to  the  downsizing  of  the  company's  minicomputer  network  and  the  even- 
tual downsizing  of  its  mainframe  computers.  It  is  an  ambitious  plan. 

However,  management  still  wants  to  know  how  it  got  trapped  without  an 
alternate  source  of  supply  for  systems  software,  and  a  member  of  the 
board  of  directors  has  explained  that  his  company  has  already  downsized 
with  good  results.  IS  management  faces  a  continuing  battle  as  it  tries  to 
rightsize  the  computer  network  and  still  maintain  credibiHty  with  corpo- 
rate management,  which  "just  doesn't  understand."  It  is  all  so  simple  in 
the  business  magazines. 

3.  Case  Study  #3 

Case  Study  #3  is  an  international  energy  company  that  generally  avoided 
the  mainframe  trap  by  installing  an  extensive  international  network  of 
System/3Xs,  and  now  AS/400s.  Systems  personnel  at  the  company  are 
convinced  that  the  AS/400  is  the  best  distributed  data  base  server  in  the 
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industry,  and  they  all  state  that  they  would  never  be  willing  to  go  back  to 
the  mainframe  environment  So  when  it  was  time  to  downsize  a  3090 
mainframe  inherited  from  a  joint  business  venture,  the  course  of  action 
seemed  clear:  downsize  to  an  AS/400,  right? 

Wrong!  When  the  transition  plan  was  submitted,  the  estimate  for  the 
downsizing  effort  was  approximately  $4  million,  including  hardware, 
communications,  and  applications  conversion.  Someone  in  corporate 
management  decided  it  was  an  appropriate  time  to  consider  the  benefits  of 
open  systems.  Why  not  convert  to  a  UNIX  open  system  so  that  eventually 
all  60  AS/400s  would  also  be  replaced?  Then  the  company  would  be  free 
to  pursue  the  joys  of  open  systems  and  install  any  computer  anywhere  and 
have  them  all  work  together  in  perfect  harmony  on  into  eternity — with 
MIPS  to  spare. 

This  stopped  the  downsizing  project  dead  in  its  tracks.  What  an  idea! 
Why  hadn't  the  downsizing  conversion  team  thought  of  that?  It  isn't  the 
downsizing  that  is  important,  it  is  getting  out  of  the  clutches  of  those 
proprietary  operating  systems  vendors.  All  of  the  open  systems  vendors 
lined  up  solidly  behind  any  plan  to  replace  60  AS/400s — even  IBM  with 
its  RS/6000. 

IBM  really  hadn't  been  selling  the  AS/400s  anyhow — the  company  had 
been  buying  them  and  installing  them.  And,  over  the  years,  it  raised  all 
kinds  of  embarrassing  questions  about  IBM's  networldng  support.  The 
company's  network  ran  without  the  "benefit"  of  a  mainframe  to  run  the 
whole  show,  and  IBM  found  this  difficult  to  comprehend;  it  thought 
everyone  had  been  caught  in  the  SNA  trap. 

INPUT  interviewed  this  company  just  as  it  was  beginning  its  analysis  of 
UNIX-based  systems  versus  the  AS/400.  Among  the  issues  identified 
were: 

•  The  cost  of  converting  a  $15  billion  investment  in  AS/400  software 
development  that  "works" 

•  The  cost  of  selecting  and  installing  systems  software  (including  a  DBMS 
and  security)  necessary  to  bring  UNIX  up  to  the  level  of  OS/400 

•  Determining  how  "open"  a  UNIX  system  really  is  once  the  data  base 
decision  has  been  reached 

•  The  cost  of  retraining  AS/400  systems  personnel  in  UNIX  and  C,  which 
is  considered  to  be  a  big  step  backward  in  terms  of  ease  of  use 

•  The  problems  of  retaining  systems  personnel  skilled  in  the  AS/400  who 
wouldn't  want  to  move  to  the  UNIX  world 
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The  leader  of  the  downsizing  conversion  group  concluded  that  it  would  be 
"disastrous"  to  replace  the  AS/400  network  because  "we  just  don't  re- 
member what  it  used  to  be  like."  However,  the  scientific  side  of  the 
company  feels  that  the  commercial  data  processing  can  be  run  as  an 
appendage  of  the  engineering  department,  which  is  primarily  concerned 
with  oil  exploration. 

The  jury  is  still  out  on  exactly  what  to  do  about  the  downsizing  effort.  It 
is  possible  it  will  just  be  delayed.  The  hardware  is  written  off,  but  the 
continuing  software  expense  was  described  as  "killing  us."  There  is 
currently  a  rumor  that  the  IS  department  could  be  cut  in  half  if  the  com- 
pany went  to  open  systems.  Needless  to  say,  this  is  not  the  opinion  of  the 
IS  department,  which  feels  that  open  systems  will  require  considerably 
more  systems  and  data  base  management  support  than  the  AS/400. 

It  is  obvious  that  downsizing  and  open  systems  issues  can  be  symptoms  of 
a  much  deeper  political  power  struggle. 

4.  Case  Study  #4 

Case  Study  #4  is  a  minicomputer  company  that  downsized  its  staff  by  over 
60%  during  the  last  decade,  has  introduced  an  open  product  line,  and  is  in 
the  process  of  overhauling  its  information  systems  infrastructure.  Its 
downsizing  priorities  are  clearly  related  to  re-engineering  systems  to 
support  the  business.  IS  management  believes  that  survival  in  today's 
market  requires  new  information  systems  that  can  support  shorter  product 
cycles  with  fewer  personnel.  Corporate  management  seems  to  agree  with 
this  assessment,  and  IS  is  assuming  additional  responsibility  during  the 
fight  for  survival. 

The  company  still  has  mainframes  installed,  and  it  is  estimated  that  it  will 
be  several  years  before  significant  progress  can  be  made  in  distributing 
data  bases  from  these  systems.  Applications  for  downsizing  to  the 
company's  UNIX-based  systems  are  selected  on  the  basis  of  improving 
productivity  of  company  personnel.  Since  staff  reductions  have  already 
been  so  severe,  the  object  is  to  reduce  overtime  and  to  improve  service  to 
customers.  Though  cost  reductions  usually  can  be  demonstrated  for 
specific  applications  that  have  been  downsized,  the  primary  emphasis  is 
on  the  struggle  to  remain  competitive. 

While  the  company  has  supported  a  major  advertising  effort  in  the  trade 
press  to  promote  the  advantages  of  open  systems,  the  commitment  to  a 
changed  information  architecture  for  internal  information  systems  demon- 
strates a  willingness  to  bet  the  company  that  the  reported  benefits  will 
actually  materialize  and  permit  the  company  to  compete  effectively  in  a 
highly  competitive  international  market.  The  objective  of  downsizing  is 
not  to  reduce  IS  costs — it  is  to  use  information  technology  to  save  the 
company.  This  is  commendable,  and  during  the  research  for  these  case 
studies  INPUT  found  that  the  company's  new  product  line  is  being  well 
received  in  the  marketplace. 
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5c  Case  Study  #5 

Case  study  #5  is  a  consumer  products  company  that  instituted  a  crash 
project  to  go  from  mainframes  (IBM  and  Unisys)  to  a  UNIX-based  open 
system  (Pyramid).  The  impetus  for  this  downsizing  effort  came  when  the 
company  was  acquired  by  an  international  conglomerate  that  had  adopted 
an  open  system  policy.  The  emphasis  was  on  replacing  mainframes  as 
rapidly  as  possible,  and  the  company  feels  that  two  key  decisions  contrib- 
uted to  the  success  of  the  downsizing  effort. 

•  The  first  decision  was  not  to  re-engineer,  but  to  convert  as  rapidly  as 
possible. 

•  The  second  decision  was  not  to  hire  a  major  systems  integrator,  but 
rather  to  plan  and  manage  the  downsizing  project(s)  with  internal  per- 
sonnel. 

It  is  felt  that  these  two  decisions  permitted  the  downsizing  project  to  be 
completed  in  a  timely  manner  with  minimal  transition  costs.  It  was  stated 
that  the  downsizing  effort  would  still  be  going  on  if  either  of  these  two 
decisions  had  been  reversed. 

The  results  achieved  were  impressive.  The  base  operating  budget  was 
reduced  from  $3.9  million  before  the  downsizing  effort  started  to  a  run- 
ning rate  of  $1.2  million  in  1992.  (It  was  estimated  that  $500,000  was 
saved  in  IBM  software  license  fees  alone.)  However,  salary  costs  have 
gone  up  slightly  (from  $2.7  million  to  $3.0  million),  even  though  head 
count  has  gone  down.  Systems  personnel  with  UNIX  and  C  experience 
are  in  demand  and  can  command  more  money.  In  addition,  to  get  the 
downsizing  effort  under  way,  more  than  900  person-days  of  training  were 
required  for  systems  and  technical  personnel — over  10  days  per  person. 

Although  the  conversion  costs  were  minimized  in  this  case,  they  were 
estimated  to  be  approximately  $2  million,  and  it  was  emphasized  that  this 
estimate  was  "very  rough."  However,  with  the  kind  of  savings  that  have 
been  reported  in  this  case,  the  effort  obviously  has  paid  off. 

It  appears  that,  when  mainframes  can  be  actually  rolled  out  the  door,  it  is 
easily  understandable  why  downsizing  has  so  much  appeal. 
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Summary  of  Published  Case  Studies 


The  role  of  the  media  in  influencing  corporate  management  to  downsize 
prompted  INPUT  to  review  published  case  studies.  Analysis  of  case 
studies  appearing  in  the  trade  press  during  the  first  three  months  of  this 
year  revealed  the  following: 

•  The  primary  platform  being  replaced,  or  planned  for  replacement,  is  the 
IBM  4381  (see  Exhibit  IM). 


EXHIBIT  11-1 


Systems  Targeted  for  Downsizing 
Replacement  Status 


IBM  4381 


IBM  Mainframe 


IBM  30XX 


Other 


V////////A^ 


□  Replaced 
^  Planned 

□  Not  Planned 
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EXHIBIT  11-2 


«  The  AS/400  has  been  the  most  successful  platform  employed  in  actually 
replacing  mainframes,  as  shown  in  Exhibit  II-2.  This  is  despite  the  facts 
that  it  is  a  proprietary  system,  and  that  IBM  has  not  seen  fit  to  market  it 
aggressively  as  a  downsizing  platform. 


Downsizing  Platforms 
Replacement  Status 


AS/400 


y///////////////;z\^ 


PC-C/S 


HP-C/S 


MS-8000 


Other 


vvVv  '^/^^ 

E]  Replaced 
^  Planned 
□  Not  Planned 


1 


1  2  3 

Number 


4 


Cost  savings,  either  actual  or  anticipated,  are  seldom  published  in  these 
case  studies,  as  is  apparent  from  Exhibit  11-3.  It  seems  that  corporate 
executives  are  not  necessarily  being  misled  by  the  trade  press — they  are 
believing  what  they  want  to  believe. 
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EXHIBIT  11-3 


Benefits  Mentioned 


IS  Investment 
(5.9%) 


Performance- 
(5.9%) 


IS  Staff 
(23.5%) 


Easy  Development 
(11.8%) 


$  Savings 
(11.8%) 


No  Mention 
(41.1%) 


C  

General  Conclusions 


The  strategic  case  studies,  the  analysis  of  published  case  studies,  and 
desk  research  on  the  distribution  of  programs  and  data  in  computer 
networks  leads  INPUT  to  conclude  that  organization  size  and  the  degree 
of  data  sharing  across  applications  determine  the  attractiveness  of  down- 
sizing from  a  technical  point  of  view.  Exhibit  II-4  shows  data  supporting 
this  view. 

•  Large  mainframes  being  used  for  shared  data  bases  are  not  attractive  for 
replacement  through  downsizing,  but  specific  applications  may  be 
downsized. 

•  The  low  end  of  the  IBM  product  line  is  especially  susceptible  to  replace- 
ment through  downsizing  because  of  the  systems  software  burden  and 
expense. 

•  Specific  cost  savings  will  be  more  likely  to  accrue  when  mainframe 
systems  are  replaced  rapidly  and  transition  costs  are  kept  to  a  minimum. 
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•  There  can  be  other  benefits  of  downsizing  (including  political  ones),  but 
these  benefits  should  be  carefully  analyzed  because  downsizing  can  be 
expensive. 

Other  conclusions  and  recommendations  are  included  in  Chapter  VII 
of  this  report. 
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Review  of  Previous  Research 


A  

An  "Upsizing"  Case  Study 

1,  Cost  Comparison-~CentraIization  versus  Decentralization 

One  of  the  first  networking  studies  that  INPUT  published  some  years  ago 
was  an  actual  case  study  of  an  international  conglomerate  that  consoli- 
dated all  of  its  standalone  computer  operations  into  a  single  data  center 
during  the  early  1970s.  [1]  This  consolidation  was  based  on  then-current 
theories  of  economy  of  scale,  and  was  essentially  an  exercise  in  "upsizing" 
within  the  IBM  product  line.  The  documented  results  of  this  consolidation 
showed  that  "upsizing"  posed  more  of  a  potential  threat  to  IBM  main- 
frame revenues  than  does  the  current  trend  toward  downsizing  (see  Exhibit 

m-i). 

*  Between  1967  and  1970,  expenditures  for  mainframe  computers  in  the 
company  had  risen  from  $5.5  million  per  year  to  just  over  $9  million. 
Then,  through  the  consolidation  effort,  mainframe  computer  costs 
plummeted  to  $2.8  million  by  1976.  This  was  accomplished  by  replac- 
ing standalone  systems  with  two  large  mainframes  in  a  central  data 
center  and  remote  job  entry  terminals  located  throughout  the  United 
States  and  Europe. 

-  Data  communications  costs  were  approximately  $1.6  million  per  year. 
(These  communications  costs  were  allocated  and  recovered  based  on 
computer  usage  and  not  actual  line  costs  for  the  remote  nodes,  so  that 
users  would  not  be  penalized  based  on  geography.) 

-  Hardware  terminal  costs  amounted  to  about  $0.75  million  per  year. 

-  The  total  cost  of  the  network  (mainframe  computers,  terminals  and 
data  communications)  was  $5.1  million. 

-  It  seemed  obvious  that  computer  networks  were  good  news  for  com- 
munications-oriented vendors  and  bad  news  for  mainframe  computer 
vendors. 
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EXHIBIT  III-1 


Decentralized  versus  Centralized  Expense 
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While  the  hardware  cost  savings  were  substantial,  the  operational  cost 
savings  of  the  centralized  network  were  even  more  impressive;  this  is 
important  when  considering  downsizing  and  decentralization. 

-  Operational  costs  (personnel,  space,  utilities,  etc.)  in  the  decentralized 
environment  were  approximately  $7.0  million. 

-  Once  centralized,  operational  costs  for  the  central  site  and  the  19 
remote  network  nodes  were  only  $3.2  million. 


-  Cost  savings  alone  do  not  reflect  the  benefits  of  centralization.  There 
are  also  the  benefits  of  improved  staff  quality  in  critical  areas  such  as 
systems  programming  and  data  communications,  and  the  improved 
reliability,  availability  and  serviceability  of  the  central  facility  (i.e., 
the  installation  of  an  uninterruptible  power  supply). 
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•  INPUT  concluded  that  the  economics  of  computer/communications 
networks  (and  economy  of  scale)  in  the  1970s  were  such  that  most  large 
organizations  could  make  more  effective  use  of  information  technology 
by  consolidating  into  large  corporate  data  centers,  and  those  organiza- 
tions that  did  not  require  very  large  mainframes  could  turn  to  computer 
services  companies  in  order  to  achieve  the  benefits  of  economy  of  scale. 
This  would  result  in  the  emergence  of  long-prophesied  computer  utili- 
ties. 

•  The  impacts  of  minicomputer-  and  microprocessor-based  workstations 
(intelligent  terminals)  on  classic  economy  of  scale  were  anticipated  in 
the  report,  and  INPUT  clients  were  advised  to  pursue  the  "orderly 
distribution  of  processing"  back  to  end  users  once  the  benefits  of  central- 
ization were  achieved. 

The  fact  that  INPUT'S  advice,  based  on  these  logical  conclusions,  was  not 
generally  acted  upon  during  the  late  1970s  (and  throughout  the  1980s) 
requires  analysis  in  order  to  understand  the  impetus  and  impact  of  down- 
sizing in  the  1990s.  Exhibit  ni-2  presents  a  node-by-node  cost  compari- 
son of  standalone  costs,  actual  data  center  charges,  and  the  projected 
charges  from  outside  services  companies  (based  on  running  actual  data 
through  the  billing  algorithms  used  by  those  vendors).  Several  conclu- 
sions pertinent  to  downsizing  can  be  inferred  from  this  chart  and  its 
underlying  data. 

•  The  relative  cost  benefits  of  centralization  into  a  single  data  center 
varied  considerably  from  node  to  node.  Savings  ranged  from  83%  of 
standalone  costs  for  node  #5  to  30%  of  standalone  costs  for  node  #15. 
This  variation  in  savings  was  not  dependent  upon  the  size  of  the  com- 
puter models  being  replaced  (the  range  of  average  cost  savings  by  the 
six  model  sizes  replaced  was  only  from  46%  to  55%).  This  leads  to 
several  conclusions: 

-  The  cost  benefits  of  centralization  are  relatively  independent  of  the 
size  of  decentralized  computer  installations  being  replaced. 

-  The  cost  benefits  actually  realized  from  centralization  are  dependent 
upon  how  effectively  computer  technology  is  being  used  (rather  than 
the  price/performance  of  the  technology  itself);  and  the  effective 
application  of  technology  is  not  determined  by  computer  system  size, 
but  by  the  quality  of  personnel  and  systems  software. 

-  However,  some  of  the  cost  benefits  of  centralization  (and  upsizing) 
are  independent  of  how  effectively  computer  technology  is  employed. 
These  benefits  are  the  lower  operational  costs  (personnel  and  environ- 
mental) that  result  from  merely  having  fewer  computer  installations. 

-  To  the  degree  that  downsizing  results  in  decentralization,  it  can  be 
assumed  that  some  of  the  cost  benefits  of  centralization  will  result  in 
increased  operating  costs  in  some  downsized  environments. 
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EXHIBIT  III-2 
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*  The  relative  costs  of  outside  services  also  convey  valuable  information 
about  the  economics  of  both  centralization  and  downsizing  (Exhibit 
in-2),  and  analysis  reveals  why  computer  utilities  have  been  so  slow  to 
develop. 

-  As  a  general  observation  it  can  be  stated  that  the  actual  data  center 
charges  were  generally  substantially  below  those  that  would  have 
been  charged  for  comparable  workload  provided  by  outside  vendors. 

-  Even  casual  observation  reveals  that  outside  computer  services  ven- 
dors were  unable  to  provide  any  cost  savings  for  a  number  of  the 
standalone  installations,  and  for  two  of  the  nodes  (4  and  11),  the  costs 
would  have  risen  substantially. 

-  One  of  reasons  that  computer  services  companies  were  not  competi- 
tive with  internal  computer  installations  (much  less  the  data  center) 
was  that  many  of  them  concentrated  on  specific  market  segments  and 
were  not  able  to  keep  their  systems  busy  or  provide  needed  services. 
The  timesharing  companies  could  not  compete  effectively  in  the  batch 
processing  market,  and  the  batch  processing  vendors  did  not  install 
systems  that  provided  fast  turnaround  (or  interactive  processing). 

The  case  study  company,  by  being  on  the  leading  edge  in  wide-area 
networking,  was  able  to  keep  its  large  mainframes  busy  by  channeling  all 
of  the  computer  workload  scattered  across  nine  time  zones  through  a 
central  computer  facility.  This  permitted  a  couple  of  mainframe  comput- 
ers, with  less  processing  power  and  less  main  memory  than  current  desk- 
top computers,  to  handle  all  of  the  data  processing  for  a  $2  billion  corpora- 
tion, poll  several  thousand  point-of-sale  terminals,  and  still  have  capacity 
to  provide  outside  computer  services. 

For  large  mainframe  installations  that  were  not  "communications  ori- 
ented"— and  in  the  early  1970s  most  of  them  were  not — the  primary 
problem  perceived  for  large  mainframes  was  how  to  "keep  the  CPU  busy." 
The  "solutions"  to  this  problem  have  created  the  current  information 
technology  architecture  that  is  the  target  for  downsizing. 

2.  Keeping  the  Mainframe  Busy 

The  "upsizing"  case  study  company  was  able  to  keep  the  CPU  busy  by 
batching  all  transactions  and  data  (some  on  distributed  minicomputers), 
transmitting  them  over  communications  lines  specifically  tailored  to 
volume  (lines  from  1200  baud  to  50KB  were  employed),  processing  these 
transactions  against  specific  files,  and  generating  all  necessary  operating 
and  management  reports.  It  operated  within  the  limitations  of  its  memory 
by  employing  multiprogramming  with  a  variable  number  of  tasks  (OS/ 
MVT). 
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The  network  worked  well  and  provided  cost-effective  information  systems 
whether  servicing  retail  stores,  manufacturing  plants,  sales  organizations, 
research  facilities,  or  a  variety  of  advanced  electronics  and  aerospace 
facilities.  It  made  effective  use  of  its  limited  (by  today's  standards) 
mainframe  MIPS  and  memory.  It  was  essentially  a  batch  processing 
engine  with  communications  capability  and  was  not  intended  to  handle 
interactive  processing;  that  was  left  to  distributed  minicomputers  and 
intelligent  workstations. 

Since  this  architecture  permitted  large  mainframes  to  gobble  up  their 
smaller  siblings  at  an  alarming  rate,  and  offloaded  interactive  work  to 
those  pesky  minicomputers,  it  is  not  surprising  that  it  did  not  have  much 
appeal  for  those  with  vested  interest  in  the  broader  spectrum  of  mainframe 
technology.  The  trick  for  them  was  to  keep  the  large  mainframes  busy  on 
something  other  than  fratricide,  and  IBM  accomplished  this  in  admirable 
fashion.  The  winning  combination  was  virtual  storage  operating  systems 
(culminating  in  MVS/ESA),  SNA  (culminating  in  the  de  facto  networking 
standard  for  commercial  data  processing),  and  data  base  management 
systems  (culminating  in  both  IMS  and  DB2). 

•  Virtual  storage  operating  systems  were  so  successful  in  consuming 
mainframe  MIPS  that  the  early  versions  spent  all  their  time  keeping 
track  of  where  everything  was,  and  the  mainframe  had  no  power  left 
over  for  running  user  "problem  programs."  This  was  called  "trashing," 
and  even  the  most  tolerant  customer  had  to  admit  that  the  systems 
overhead  was  getting  a  little  high.  The  trashing  problem  was  "fixed," 
but  the  overhead  of  virtual  storage  operating  systems  lives  on  in  terms  of 
both  MIPS  consumed  and  real  memory  required  to  house  the  operating 
system.  Virtual  storage  has  a  big  role  to  play  on  both  clients  and  servers 
in  the  downsized  environment,  and  the  quality  of  implementation — in 
hardware  and/or  software — -will  be  an  important  architectural  determi- 
nant of  performance  in  the  downsized  environment. 

•  SNA  was  designed  to  keep  practically  all  processing  on  the  mainframe 
host,  and  in  this  it  has  been  remarkably  successful.  Transient  phenom- 
ena such  as  having  the  mainframe  refresh  "clocks"  on  terminal  screens, 
and  routing  messages  thousands  of  miles  through  a  mainframe  when  the 
recipient  is  practically  next  door,  have  occasionally  surfaced  to  warn 
users  of  this  excessive  mainframe  orientation.  However,  commercial 
customers  have  been  surprisingly  tolerant  as  they  have  continued  to 
upgrade  mainframes  to  perform  functions  that  could  be  more  economi- 
cally handled  at  other  levels  of  the  processor  hierarchy.  There  are  many 
such  "improper"  functions  (and  applications)  trapped,  and  hidden,  on 
mainframes  by  SNA;  and  these  have  been  and  continue  to  be  attractive 
targets  for  downsizing. 
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•  One  of  the  reasons  users  found  it  difficult  to  keep  large  mainframe  CPUs 
busy  is  that  commercial  applications  have  traditionally  been  I/O-bound 
(unlike  scientific  and  engineering  applications  that  have  been  compute- 
bound).  Data  base  management  systems  have  gone  a  long  way  toward 
"correcting"  the  commercial  imbalance.  Transactions  that  required  the 
execution  of  a  few  hundred  (or  less)  instructions  in  a  serial  batch  envi- 
ronment suddenly  started  requiring  hundreds  of  thousands  of  instruc- 
tions when  a  DBMS  (IMS)  was  installed,  and  the  performance  problems 
associated  with  the  relational  model  kept  DB2  from  becoming  a  product 
for  approximately  10  years.  The  relational  model  is  the  data  model  of 
choice  in  the  downsized  environment. 

Mainframe  computers  exist,  and  are  necessary,  to  run  this  complex  set  of 
systems  software.  The  biggest  investment  that  mainframe  users  have 
made  is  not  in  their  (COBOL)  applications;  it  is  in  following  IBM's 
operating  systems,  network  architecture,  and  data  base  management 
strategies.  It  is  the  whole  top-heavy  information  architecture  that  resulted 
from  these  strategies  that  is  now  under  attack  by  the  advocates  of  downsiz- 
ing. The  targets  of  this  attack  vary  considerably  in  terms  of  their  vulner- 
ability. 

3.  Target  Selection 

It  is  assumed  that  scientific  and  engineering  work,  whether  on  a  main- 
frame or  a  minicomputer,  will  naturally  gravitate  toward  the  most  cost- 
effective  platform.  The  cost  savings  are  easily  measured  and  relatively 
easy  to  obtain.  The  same  applies  for  text  processing  and  publishing 
applications  in  the  commercial  world.  It  is  not  necessary  to  invent  new 
terminology  or  have  conferences  to  encourage  computer  users  (or  even  IS) 
to  adopt  innovations  with  obvious  benefits. 

Current  downsizing  efforts  are  directed  toward  mainstream  commercial 
applications  involving  large  data  bases  and  transaction  processing,  and 
here  the  benefits  are  not  so  obvious.  However,  there  are  attractive  targets 
of  opportunity  for  downsizing  mainframe  commercial  applications. 

Smaller  mainframe  systems  (such  as  the  4381)  that  serve  as  bridge  sys- 
tems to  the  MVS/ESA,  SNA,  IMS-DB2  worlds  are  especially  vulnerable 
to  attack.  They  can  hardly  carry  the  overhead  burden  of  the  systems 
software  and  have  little  capacity  left  over  for  user  applications.  It  is  not 
by  chance  that  many  of  the  publicized  cases  of  mainframes  being  replaced 
by  downsizing  are  4381s. 

In  addition,  some  application  systems  are  attractive  regardless  of  the  size 
of  mainframe  involved.  They  simply  don't  require  either  the  functionality 
or  robustness  of  mainframe  systems  software  because  they  are  relatively 
independent  in  their  data  dependencies.  The  overhead  burden  and  com- 
plexity of  mainframe  systems  software  in  these  cases  is  not  justified,  and 
these  applications  provide  attractive  targets  for  downsizing  to  more  cost- 
effective  platforms. 


e  1992  by  INPUT.  Reproduction  Prohibited. 


ni-7 


CASE  STUDIES  IN  DOWNSIZING 


INPUT 


Cost/benefit  problems  start  to  arise  when  applications  have  data  dependen- 
cies across  organizational  lines— in  other  words,  when  the  applications 
environment  requires  the  large  data  bases  and  high  transaction  rates  that 
mainframe  systems  software  was  designed  to  accommodate.  However, 
even  then  it  is  probable  that  many  of  these  applications  can  be  re-engi- 
neered to  take  advantage  of  advances  in  information  technology,  and 
specific  mainframe  functions  can  be  cost  effectively  downsized. 

The  central  issue  that  will  arise  as  downsizing  proceeds  will  be  the  relative 
advantages  (and  disadvantages)  of  centralization  versus  decentralization. 
Will  the  theoretical  cost  savings  based  on  improvement  in  hardware  price/ 
performance  disappear  because  of  increased  operating  costs  in  the  decen- 
tralized (or  distributed)  environment?  Because  INPUT  was  aware  of  the 
benefits  of  "upsizing"  (centralization),  it  decided  that  the  current  trend 
toward  downsizing  had  to  be  carefully  analyzed  to  determine  the  cost/ 
benefit  trade-offs  between  the  two  environments. 

Let  us  review,  very  briefly,  the  pertinent  highlights  of  INPUT'S  downsiz- 
ing research  to  this  point 


B  

Putting  Downsizing  in  Perspective 

1.  Platform  Report  Card 

INPUT  asked  IS  management  to  rank  the  major  hardware  platforms  on 
various  attributes;  the  results  are  shown  in  Exhibit  ni-3=  Although  the 
chart  may  seem  a  littie  complex,  the  "grades"  on  the  "report  card"  are  not. 
IS  management  feels  strongly  that: 

•  Mainframes  excel  in  all  of  the  attributes  that  are  usually  deemed  impor- 
tant for  traditional  commercial  applications,  even  if  this  is  accomplished 
at  the  expense  of  "complexity." 

•  Minicomputers  are  best  suited  for  distributed  data  servers. 

•  RISC-based  workstations  are  best  for  scientific  (and  engineering)  appli- 
cations. 

•  PCs  stand  out  as  being  easy  to  use  and  cost  effective. 
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EXHIBIT  III-3 
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While  vendors  generally  agreed  with  IS  management's  evaluation  on  14  of 
the  18  attributes,  they  dissented  on  the  following: 

«  Vendors  ranked  PCs  best  for  connectivity  and  applications  software,  but 
mainframes  were  a  close  second  by  having  "grades"  of  91  and  97, 
respectively. 

•  Vendors  ranked  RISC-based  workstations  better  than  PCs  for  open 
architecture,  and  better  than  minicomputers  as  distributed  data  servers. 
In  addition,  RISC-based  workstations  shared  the  top  ranking  for  cost 
effectiveness  with  PCs  in  the  vendor  rankings. 

Despite  the  fact  that  both  IS  management  and  vendors  gave  high  grades  to 
mainframes  on  many  of  the  essential  attributes  of  mainstream  commercial 
applications,  both  sets  of  respondents  agreed  that  mainframes  would  cease 
to  be  the  predominant  platforms  for  many  commercial  applications  during 
the  1990s.  Generally  speaking,  downsizing  will  favor  PCs  and  worksta- 
tions at  the  expense  of  both  mainframes  and  minicomputers,  with  IS 
management  more  favorably  disposed  toward  PCs  and  vendors  more 
favorably  disposed  toward  RISC  workstations. 

However,  the  strong  support  for  downsizing  remains  difficult  to  rational- 
ize in  light  of  the  strong  support  exhibited  for  mainframe  commercial 
systems  in  Exhibit  111-3. 

2e  Factors  Prompting  Downsizing 

According  to  IS  management,  the  top  factors  prompting  downsizing  were 
all  directly  related  to  reducing  the  expenses  associated  with  information 
technology,  as  shown  in  Exhibit  111-4.  While  vendors  agreed  that  the  most 
important  factor  prompting  downsizing  was  reduced  IS  costs,  they  felt  that 
improved  user  service  and  control  were  just  as  important  (ranking  those 
factors  at  99%  and  95%,  respectively). 

Though  IS  management  felt  that  cost  savings  were  the  primary  factors 
prompting  downsizing,  it  was  much  more  difficult  to  get  agreement  that 
cost  savings  would  actually  be  realized. 

•  Only  65%  of  IS  management  felt  that  hardware  costs  would  actually  be 
reduced  (compared  to  85%  for  vendors). 

•  Only  62%  felt  that  downsizing  would  reduce  the  role  and  expense  of  IS 
(compared  to  78%  for  vendors). 

•  Only  46%  felt  that  software  expense  would  be  reduced,  and  vendors 
were  in  agreement  with  this  assessment  since  only  44%  of  them  felt  that 
software  expense  would  be  reduced. 
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Factors  Prompting  Downsizing 
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Factors 


Key 

Factor 

IS 

Vendor 

1 

Lower  IS  Costs 

100 

100 

2 

Hdwr.  Price/Perf. 

95 

88 

3 

Reduced  Development  Cost 

80 

66 

4 

Improved  User  Service 

61 

99 

5 

User  Control 

58 

95 

6 

Organizational  Flexibility 

49 

75 

7 

Need  to  Re-engineer 

46 

56 

8 

Improve  Mgmt.  Info.  Quality 

42 

82 

9 

Decentralize  (Mgmt.  Desire) 

37 

32 

10 

Open  Systems 

20 

51 

11 

Specification  SW 

17 

20 

•  Only  33%  felt  that  downsizing  would  result  in  better  management 
control  of  information  resources  (compared  with  67%  for  vendors). 

It  can  be  concluded  that  some  of  the  impetus  for  downsizing  is  coming 
from  corporate  executives  and  end  users,  and  that  IS  management  is  not 
especially  confident  that  the  goals  and  objectives  of  downsizing  will  be 
realized. 
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3.  Factors  Inhibiting  Downsizing 

Both  IS  management  and  vendors  agree  that  the  main  factor  inhibiting 
downsizing  is  associated  with  data  base  management  (see  Exhibit  III-5). 
This  factor  was  defined  as  being  a  problem  of  data  quality  in  terms  of  data 
base  integrity,  synchronization,  and  security;  it  is  precisely  here  that  the 
strengths  (as  defined  by  IS  management  and  vendors)  of  the  mainframe 
and  centralization  come  into  play. 


Factors  Inhibiting  Downsizing 


01  

1      23456789     10  11 
Factors 


Key 

Factor 

IS 

Vendor 

1 

Data  Quality  Problems  (ISS) 

100 

100 

2 

Cost  of  Reprogramming 

82 

84 

3 

Increased  Network  Complexity 

81 

57 

4 

Appl.  SW  Not  Available 

69 

53 

5 

Cost  of  DB  Conversion 

64 

62 

6 

Inadequate  Sys.  SW 

61 

71 

7 

Centralized  Control 

46 

56 

8 

Increased  DBM  Costs 

41 

28 

9 

Vendor  Reliability 

30 

34 

10 

Increased  SW  Expense 

25 

12 

11 

Loss  of  Vendor  Support 

17 

31 
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What  IS  management  seemed  to  be  saying  was  this: 

®  Operating  executives  and  end  users  think  they  can  cut  information 
systems  costs  by  taking  advantage  of  the  vastly  improved  price/perfor- 
mance of  new  technologies  such  as  RISC  workstations  and  networked 
PCs. 

•  We  aren't  too  sure  that  any  actual  cost  savings  will  result  from  downsiz- 
ing, but  the  groundswell  is  so  great  that  we  have  to  "go  with  the  flow." 

•  There  is  a  very  real  possibility  that  downsizing  may  result  in  data  prob- 
lems if  we  aren't  careful. 

INPUT  doesn't  know  how  individual  IS  managers  are  handling  this 
situation,  but  it  is  certain  that  a  high  percentage  (over  80%)  had  specific 
downsizing  plans,  and  many  projects  were  already  under  way.  This  led 
INPUT  to  conclude  that  both  the  economics  of  downsizing  and  the  techno- 
logical risks  associated  with  a  new  information  architecture  required  more 
detailed  study.  INPUT  decided  to  focus  on  the  architectural  issues  first. 


c  

Systems  Architectures  for  Downsizing 


INPUT  determined  that  an  analysis  of  systems  architectures  required 
looking  "behind  the  screen,  at  the  screen,  and  beyond  the  screen."  In  the 
process  of  doing  this  INPUT  isolated  some  fundamental  competing  con- 
cepts among  the  mass  of  "terminological  inexactitude"  that  was  identified 
at  the  beginning  of  the  research  when  even  such  terms  as  downsizing, 
client/server,  and  application  were  at  issue. 

Exhibit  ni-6  reviews  what  is  seen  behind  the  screen,  at  the  screen,  and 
beyond  the  screen. 
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EXHIBIT  III-6 


Downsizing  Issues 


Behind  the  Screen 


•  RISC  vs.  CICS 

•  UNIX  vs,  proprietary 

•  DBMS  vs.  DDBM 

•  Host  vs.  peer-to-peer 

•  Client/server  vs. 
cooperative  processing 


At  the  Screen 


•  "Applications"  vs.  tools 

•  GUIs  vs.  reality 

•  Ease  of  use  vs.  quality 

•  Productivity  vs.  "efficiency' 

•  Human  vs.  system 

•  Information  vs.  knowledge 


Beyond  the  Screen 


•  Centralized  vs.  decentralized 

•  Top-down  vs.  bottom-up 

•  IS  vs.  management 

•  Innovation  vs.  culture 

•  Control  vs.  empowerment 


1.  Behind  the  Screen 


•  Hardware  architecture  has  resurfaced  as  a  controversial  issue  that  pits 
the  advocates  of  reduced  instruction  set  computers  (RISC)  versus  com- 
plex instruction  set  computers  (CISC).  INPUT  made  the  following 
observations: 
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-  This  is  not  a  new  issue.  What  should  be  built  into  hardware  and  what 
should  be  left  for  software  has  been  a  controversial  subject  among 
computer  architects  for  decades. 

-  MIPS  are  a  poor  measure  of  the  performance  (much  less  throughput) 
of  RISC  processors  because  so  much  dependency  is  placed  upon  the 
quality  of  systems  software  (specifically  compilers). 

-  In  addition,  the  RISC  architecture  is  best  suited  for  binary  arithmetic 
rather  than  data  manipulation — a  fact  that  is  important  when  downsiz- 
ing commercial  applications. 

•  The  UNIX  versus  proprietary  operating  system  argument  has  also  been 
going  on  for  more  than  a  decade,  but  it  has  now  taken  on  the  attributes 
of  a  holy  war  that  finds  the  sects  of  the  open  systems  fanatics  battling 
among  themselves. 

-  UNIX  has  yet  to  prove  itself  in  the  mainstream  commercial  market, 
and  it  is  not  currently  competitive  with  mainstream  operating  systems 
at  the  mainframe  and  minicomputer  levels. 

-  It  has  had  only  minimal  impact  in  the  personal  computer  market,  and 
operating  systems  developments  (specifically  OS/2)  threaten  to  leap- 
frog its  capability  there. 

-  It  is  unlikely  that  a  "standard"  UNIX  will  ever  emerge  from  the 
various  competing  efforts,  and  is  doubtful  UNIX  will  ever  catch  up 
with  major  proprietary  operating  systems  for  commercial  applications. 

•  While  relational  (or  relational-like)  data  base  management  systems  are 
the  clear  winners  in  the  downsizing  (or  distributed)  environment,  the 
many  problems  associated  with  distributed  data  base  management  have 
yet  to  be  solved.  This  is  the  reason  that  IS  management  expresses 
concerns  about  data  base  integrity,  synchronization  and  security.  The 
following  conclusions  can  be  reached  about  this  key  issue: 

-  Existing  corporate  data  bases  (many  of  them  based  on  the  hierarchical 
model  as  implemented  in  IMS)  will  not  be  readily  replaced  for  many 
years. 

-  IBM's  Systems  Application  Architecture  (SAA)  is  the  most  compre- 
hensive plan  for  distributed  data  base  management  (DDBM)  that  is 
cun:ently  available,  and  downsizing  is  heavily  dependent  upon 
DDBM. 

-  Most  downsizing  efforts  will  require  integration  with  SAA  data  bases 
at  some  level  in  the  network  hierarchy. 
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•  SNA  is  the  backbone  network  of  choice  in  the  commercial  world.  De- 
spite all  of  the  talk  about  open  systems,  surprisingly  little  progress  has 
been  made.  SNA  has  been  excruciatingly  slow  in  the  distribution  of 
function  from  mainframe  computers  despite  all  of  the  talk  about  peer-to- 
peer  architectures.  During  the  course  of  INPUT'S  downsizing  research, 
IBM  has  (again)  endorsed  its  advanced  peer-to-peer  networking 
(APPN),  but  it  currently  exists  only  on  0S/4(X)  and  OS/2  platforms.  The 
mighty  host  condescends  to  downsizing  with  extreme  reluctance. 

•  The  IBM  model  for  downsizing  is  cooperative  processing,  which  has 
been  roughly  defined  for  over  five  years  and  is  the  key  architecture  for 
SAA.  Client/server  is  a  relatively  recent  term  that  is  more  all-encom- 
passing than  cooperative  processing  (though  there  are  some  who  would 
dispute  this).  Cooperative  processing  depends  upon  DDBM;  client/ 
server  is  used  for  everything  from  shared  file,  through  file  transfer,  to 
full  distributed  data  base  management  (or  cooperative  processing). 
However,  it  doesn't  make  any  difference  whether  you  are  downsizing 
firom  mainfi°ames  or  integrating  a  bunch  of  personal  computers  on  a 
LAN,  you  will  still  wind  up  with  a  "client/server  architecture." 

2.  At  the  Screen 

The  screen  is  where  the  human  meets  the  machine,  and  everything  that 
goes  on  behind  the  screen  should  be  transparent,  and  of  no  concern,  to  the 
user.  Computer  vendors  have  been  saying  this  for  years,  but  try  to  tell  that 
to  the  poor  soul  who  is  struggling  with  memory  management  on  a  PC,  or 
who  is  confronted  with  unexplained  system  crashes  or  network  failure.  A 
lot  of  people  may  have  become  "computer  literate"  during  the  1980s,  but 
this  type  of  literacy  has  come  at  high  cost. 

Much  of  this  we  blame  on  software  vendors  who  seem  to  have  little 
awareness  of  how  computers  are  actually  employed  in  business. 

•  The  clearest  evidence  of  this  is  the  redefinition  of  die  term  "application," 
which  has  been  misapplied  to  include  applications  enabling  tools  at  the 
personal  computer  level.  Spreadsheets  and  DBMSs  are  not  "applica- 
tions"— they  make  no  direct  contribution  to  accomplishing  the  role  of 
the  individual  or  organization  employing  them.  This  will  become 
patentiy  clear  as  users  attempt  to  downsize  real  applications  using 
shrink-wrapped  tools. 

•  Graphic  user  interfaces  (GUIs)  are  currentiy  all  the  rage,  but  they  do  not 
hide  what  is  behind  die  screen.  Just  ask  the  users  of  Windows  3.0 
whether  or  not  they  had  to  be  concerned  about  what  was  going  on  when 
their  systems  failed.  Now,  we  have  Windows  3.1  and  it  is  being  labeled 
an  "operating  system."  It  just  ain't  so  folks — DOS  remains  the  operat- 
ing system  regardless  of  how  many  shells  and  pretty  wrapping  paper  we 
put  around  it.  Even  such  restrictions  as  the  length  of  file  names  can  be 
extremely  annoying  to  those  accustomed  to  the  Apple  n  or  Macintosh. 
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«  The  underlying  architecture  at  the  screen  also  becomes  important  in 
terms  of  trade-offs  between  ease  of  access  (to  either  other  systems  or 
data)  and  data  quality.  There  are  good  reasons  that  published  security 
violations  usually  involve  UNIX-based  networks,  and  viruses  plague 
personal  computers. 

•  It  is  becoming  increasingly  apparent  that  putting  white-collar  workers  at 
computer  screens  has  not  made  them  more  productive,  and  yet  employ- 
ees are  theoretically  more  efficient  in  what  they  are  doing.  This  problem 
is  not  going  to  go  away  by  providing  more  hardware  or  software  tools — 
the  office  process  beyond  the  screen  must  be  addressed. 

«  Depending  upon  the  architectural  quality  of  the  specific  application,  it  is 
possible  to  put  humans  in  an  adversarial  relationship  with  the  system. 
When  the  system  has  the  capability  of  measuring  human  "productivity" 
down  to  the  keystroke  (or  mouse  cUck),  the  office  worker  can  feel  as 
chained  to  the  machine  as  did  any  piece-work  employee  before  the  days 
of  blue-collar  unions.  And  this  adversarial  relationship  is  not  restricted 
to  clerical  workers;  the  term  "intellectual  rate  busting"  has  already 
begun  to  creep  into  trade  literature.  [3] 

•  There  is  a  general  misconception  that  information  by  its  very  nature  is 
good,  and  that  anything  displayed  on  the  screen  has  value.  This  is  not 
true.  It  is  obvious  that  the  quality  of  information  will  depend  upon  the 
data  base,  but  it  should  also  be  recognized  that  the  quality  of  information 
depends  upon  the  knowledge  of  the  person  who  developed  the  informa- 
tion. It  is  easy  for  anyone  to  develop  pretty  reports,  but  this  does  not 
mean  that  the  content  can't  be  nonsense.  The  architecture  of  the  infor- 
mation system — whether  decision  support  or  voice  mail — should  include 
the  provision  for  input  of,  and  access  to,  human  knowledge. 

3.  Beyond  the  Screen 

Beyond  the  screen  of  information  technology,  the  impacts  of  the  long- 
awaited  "information  age"  are  taking  place.  In  parallel  with  the  downsiz- 
ing of  mainframe  computer  systems,  there  is  currently  a  management 
trend  toward  organizational  downsizing.  This  trend  manifests  itself  in 
reduced  head  count — especially  in  middle  management  As  the  organiza- 
tional structure  changes,  so  does  the  "information  architecture"  of  the 
enterprise. 

Though  it  is  difficult  to  determine  the  exact  relationship  between  techno- 
logical downsizing  and  management  downsizing,  there  is  no  question  that 
there  is  a  heavily  interdependent  relationship  between  the  two.  The  most 
important  issues  associated  with  downsizing  depend  upon  the  nature  of 
this  relationship.  They  are  as  follows: 
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•  The  previously  mentioned  issue  of  centralization  versus  decentralization 
goes  well  beyond  the  economics  of  the  situation.  For  example,  it  has 
recentiy  been  reported  that  some  CIOs  are  downsizing  themselves  out  of 
their  jobs.  [4]  As  the  IS  function  is  decentralized  to  operating  levels,  the 
Indians  get  dispersed  and  there  is  no  need  for  a  chief. 

•  In  the  decentralized  environment,  the  classic  top-down  design  concepts 
of  structured  programming  are  abandoned  for  a  bottom-up  approach  that 
is  reminiscent  of  the  early  days  of  computings  Though  this  dramatic 
architectural  shift  has  been  prompted  by  the  failure  of  the  "big  bang" 
theory  of  systems  development  (where  all  of  the  data  requirements  for 
all  time  had  to  be  defined  first),  it  is  wise  to  remember  that  the  horrible 
integration  problems  associated  with  individual  applications  were  what 
prompted  the  development  of  corporate  data  bases.  The  pendulum 
always  seems  to  swing  too  far. 

•  The  IS  department  has  been  placed  in  an  adversarial  position  with 
operating  management  because  it  has  frequently  been  identified  as  an 
extension  of  the  corporate  controller  and  planning  functions.  Many  line 
managers  feel  they  are  being  asked  to  supply  data  to  feed  information 
systems  and  receive  very  little  help  with  their  information  requirements. 
When  IS  spends  too  much  time  concentrating  on  the  screen  and  what  is 
behind  it,  the  needs  of  the  business  have  not  been  well  served. 

•  Regardless  of  the  rationale  for  downsizing,  there  is  no  question  that 
major  innovations  (both  technological  and  managerial)  will  occur  rap- 
idly in  the  1990s.  It  is  doubtful  that  organizational  culture  will  be  able 
to  keep  up  with  these  changes.  The  IS  department  is  very  much  a  part  of 
the  establishment,  and  the  establishment  does  not  change  gracefully — 
that  is  what  cultural  lag  is  all  about.  (It  was  recendy  reported  that  Bruce 
(Tog)  Tognazzini — Apple's  "Evangelist  of  the  Interface" — has  left  for 
the  less  sttuctured  environment  of  Sun  Microsystems.  Cultural  lag 
works  both  ways.) 

•  The  major  downsizing  issue  is  that  of  central  control  versus  individual 
empowerment.  It  will  require  drastic  changes  in  the  mindset  of  both 
management  and  employees  if  desired  results  are  to  be  achieved.  Al- 
though information  technology  is  an  important  ingredient  of  downsizing, 
the  human  and  organizational  considerations  predominate.  Achieving  a 
balance  between  central  control  and  empowerment  will  be  the  key  to 
success  in  the  1990s. 

Because  of  the  complexity  of  the  issues  outiined  above,  INPUT  decided 
that  strategic  case  studies  (rather  tiian  tactical  case  studies,  which  are 
related  to  specific  projects  and/or  applications)  were  necessary. 
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Strategic  Case  Studies 


The  subjects  of  these  strategic  case  studies  have  been  drawn  from  among 
leaders  in  the  application  of  information  technology.  This  means  that  they 
have  made  a  continuing  effort  to  rightsize  and  take  advantage  of  emerging 
technologies.  They  upsized  when  economy  of  scale  dictated;  they  distrib- 
uted processing  where  appropriate;  they  downsized  before  the  term  be- 
came popular;  and  now  they  confront  the  1990s  with  knowledge  of  both 
the  potential  and  the  limitations  of  technological  "solutions"  that  are 
currently  in  vogue. 

Precisely  because  most  of  them  have  made  effective  use  of  information 
technology  as  it  has  emerged,  the  value  of  their  experience  and  knowledge 
frequently  lies  in  defining  the  limitations  (rather  than  the  potential)  of  new 
information  technology.  IS  management  in  these  case  study  organizations 
frequently  talks  about  information  architectures  and  data  quality  rather 
than  MIPS  and  GUIs.  This  is  not  always  popular  with  corporate  execu- 
tives and  end  users  who  have  gained  some  measure  of  computer  literacy 
through  experience  with  personal  computers  and  reading  the  trade  press. 

T.S.  Eliot  once  raised  the  following  questions: 

Where  is  the  wisdom  we  have  lost  in  knowledge? 

Where  is  the  knowledge  we  have  lost  in  information? 

(The  Rock,  1934) 

These  are  appropriate  questions  to  ask  ourselves  as  we  proceed  in  the 
"Information  Age."  In  fact,  knowing  what  we  know  today  it  is  possible  to 
ask  some  additional  questions: 

Where  is  the  information  we  have  lost  in  data? 

Where  are  the  data  we  have  lost  in  computers? 
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These  strategic  case  studies  have  been  selected  with  the  intent  of  identify- 
ing data  in  computers,  information  in  data,  knowledge  in  information,  and 
wisdom  in  knowledge.  In  other  words,  we  will  isolate  the  major  manage- 
ment and  technical  issues  that  are  driving  the  trend  toward  downsizing, 
and  the  approaches  that  are  being  taken  to  reconcile  these  issues. 

•  Case  Study  #1  is  a  university  that  is  in  the  process  of  defining  a  long- 
range  information  architecture  (which  it  assumes  will  be  cHent/server), 
and  it  developed  a  comprehensive  cost  model  for  use  in  determining 
where  costs  will  decrease  and  increase. 

•  Case  Study  #2  is  a  railroad  that  has  been  on  the  leading  edge  in  adapting 
computer  and  communications  technologies  to  the  operational  aspects  of 
its  business.  It  has  gone  through  various  phases  of  centralization  and 
decentralization  in  employing  information  technology  to  build  the  data 
bases  necessary  to  serve  its  customers.  It  nevertheless  finds  itself  en- 
snared in  an  expensive  systems  software  trap  on  its  mainframe  comput- 
ers. 

•  Case  Study  #3  involves  an  international  energy  company  that  has  essen- 
tially managed  to  avoid  the  large  mainframe  trap,  only  to  find  itself 
currently  embroiled  in  an  open  versus  proprietary  systems  controversy 
when  attempting  to  downsize  an  inherited  IBM  mainframe.  An  exten- 
sive AS/400  network  is  being  threatened  by  UNIX  servers. 

•  Case  Study  #4  is  a  minicomputer  vendor  that  has  experienced  major 
organizational  downsizing  and  is  now  attempting  to  recover  by  embrac- 
ing open  systems  in  its  product  line  and  in  its  internal  systems  operation. 
Improved  internal  systems  are  viewed  as  being  essential  in  order  to 
remain  competitive,  but  mainframes  will  remain  installed  for  some  time. 

•  Case  Study  #5  is  a  medium-sized  consumer  products  company  owned  by 
a  major  international  conglomerate  that  is  committed  to  open  systems. 
The  case  study  company  eliminated  mainframes  by  pursuing  an  aggres- 
sive conversion  program  supported  by  a  substantial  upgrading  of  IS  staff 
skills. 

In  the  chapter  following  the  strategic  case  studies,  INPUT  will  analyze 
some  of  the  downsizing  case  studies  that  have  appeared  in  the  trade  press. 
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A  

Case  Study  #l--Modeling  Costs  in  the  Downsizing  Environment 

h  Background 

This  case  study  organization  is  a  major  university  that  has  contributed 
substantially  to  the  development  of  Silicon  Valley  and  the  hardware/ 
software  technologies  that  support  downsizing.  Its  IS  department  has  been 
on  the  leading  edge  in  developing  systems  software,  networking,  and 
office  automation.  The  campus  has  served  as  a  test  site  for  many  ad- 
vanced hardware/software  technologies.  The  overall  computing  environ- 
ment is  fragmented  among  administrative,  academic,  and  research  depart- 
ments, and  the  professional  schools.  A  vast  assortment  of  mainframes, 
minicomputers,  RISC  workstations  and  personal  computers  are  installed 
and  connected  to  the  campus  network. 

The  primary  focus  of  this  case  study  is  on  the  potential  impact  of  downsiz- 
ing on  the  mainframe  data  center  (IBM  ES/9000)  that  supports  centraUzed 
financial  and  administrative  applications,  as  well  as  such  centralized 
services  as  electronic  mail,  appointment  scheduling,  and  on-line  forms; 
and  on  the  communications  services  department  that  is  responsible  for  the 
campus  network.  These  centralized  appUcations  and  services  have  been 
implemented  with  heavy  reliance  on  home-grown  systems  and  communi- 
cations software,  and  institutional  data  bases  have  been  built  (and  are 
being  managed)  using  an  in-house-developed  DBMS. 

Since  these  centralized  applications  and  services  have  been  in  place  for  a 
number  of  years,  a  management  decision  was  made  (a  few  years  ago)  to 
"disperse"  IS  personnel  to  user  departments.  However,  the  data  center 
retains  a  cadre  of  operations,  systems  programming,  and  information 
systems  professionals.  Data  center  costs  are  accounted  for  meticulously 
and  recovered  based  on  use  of  the  data  center. 

While  some  of  the  accounting  practices  of  the  data  center  are  dictated  by 
government  research  contracts,  they  are  quite  common  in  any  large  shared 
computing  facility.  It  is  also  quite  common  that  users  are  never  satisfied 
with  data  center  rates,  and  this  is  especially  true  in  an  environment  where 
there  are  so  many  computer  experts  (both  real  and  imagined)  scattered 
among  the  user  base. 

It  is  little  wonder  that  downsizing  is  an  extremely  popular  subject.  Costs 
are  under  close  scrutiny;  users  are  extremely  knowledgeable  about  down- 
sizing technologies;  and  universities  are  information  oriented.  It  is  also 
little  wonder  that  IS  management  is  assuming  that  the  architectural  trend 
of  the  1990s  will  be  toward  client/server  computing.  The  past  technologi- 
cal and  political  history  of  the  university  indicates  clearly  who  will  prevail 
in  any  controversy  between  the  central  IS  function  and  user  departments — 
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empowerment  is  a  way  of  life  in  an  academic  environment  However,  it  is 
surprising  that  IS  management  is  not  only  focusing  on  a  long-range  infor- 
mation architecture,  but  also  on  the  cost  and  funding  of  downsizing. 
EvTPUT  found  a  little  wisdom  among  all  that  university  knowledge  that 
sometimes  gets  lost  in  the  overload  of  information. 

a.  Factors  Prompting  Downsizing 

The  specific  factors  prompting  downsizing  at  the  university  are: 

•  Lower  IS  personnel  costs 

•  Better  hardware  price/performance 

•  The  ability  to  use  off-the-shelf  software  packages  (both  systems  and 
applications) 

•  Improved  decision  support  systems  for  both  the  administrative  and  the 
academic  sides  of  the  university 

b.  Factors  Inhibiting  Downsizing 

The  factors  viewed  as  inhibiting  downsizing  are: 

•  The  data  and  applications  that  are  installed  on  the  mainframe  are  diffi- 
cult to  replace  because  the  university  standardized  on  its  own  internally 
developed  DBMS  in  1982.  (While  this  problem  may  appear  unique  to 
the  university,  it  is  comparable  to  having  any  hierarchical  or  network 
DBMS  as  the  applications  foundation — the  relational  model  reigns 
supreme  in  the  downsizing  environment.) 

«  There  is  an  existing  and  continuing  investment  in  mainframe  technol- 
ogy. It  is  estimated  that  at  least  two  more  major  mainframe  upgrades 
will  be  required  before  growth  can  be  stabilized,  much  less  downsized. 
(Once  caught  on  the  mainframe  growth  escalator  it  must  be  ridden  to  the 
next  floor  before  one  can  start  to  descend — trying  to  run  frantically 
down  the  up  escalator  is  extremely  dangerous!) 

•  The  internal  application  development  tools  and  infrastructure  are  "differ- 
ent" than  those  available  on  the  commercial  market — sometimes  they 
are  better  and  sometimes  not  as  good,  but  they  are  always  different.  In 
the  case  of  the  campus  network,  there  are  currently  no  commercially 
available  products  that  could  effectively  integrate  the  hodge-podge  of 
equipment  that  is  currently  installed. 

•  Financial  applications  will  be  extremely  difficult  (if  not  impossible)  to 
manage  during  any  transition  period — even  if  it  could  be  demonstrated 
that  downsizing  might  be  cost  effective.  As  long  as  these  applications 
remain  on  mainframes,  the  economics  of  downsizing  ancillary  applica- 
tions become  highly  questionable. 
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c.  Applications 

New  applications,  such  as  image  processing,  will  be  implemented  using 
new  technology.  For  example,  the  university  is  using  RS/6000s  for  its 
image  processing  prototype  systems c  (The  cost  of  running  ImagePlus  on 
an  IBM  mainframe  that  does  not  have  IMS,  DB2,  and  CICS  installed  was 
more  than  enough  to  discourage  any  thoughts  of  "experimenting"  with 
image  processing  on  the  mainframe.)  It  is  probable  that  these  new  appli- 
cations will  eventually  "attract"  their  data  processing  components  from 
mainframes.  In  other  words,  it  will  be  easier  and  more  cost  effective  to 
integrate  the  data  base  down  to  the  image  base,  rather  than  to  integrate  the 
image  base  upward  to  the  data  base. 

As  far  as  actual  planned  downsizing  is  concerned,  it  seems  obvious  that  ad 
hoc  reporting  will  be  downsized,  and  the  "dispersal"  of  the  IS  function  to 
user  departments  facilitates  this  approach.  Pair-wise  connectivity  between 
mainframe  data  bases  and  departmental  (or  personal)  data  bases  is  a 
natural  consequence  of  making  systems  personnel  available  to  user  depart- 
ments. However,  it  has  already  been  determined  that  IS  personnel  as- 
signed to  the  user  departments  have  practically  no  time  for  any  type  of 
development  work — they  are  too  busy  doing  routine  maintenance,  ad  hoc 
reporting  and  end-user  consulting.  End  users  are  satisfied  in  this  environ- 
ment, but  management  tends  to  get  frustrated  because  new  development 
suffers.  Therefore,  a  client/server  infrastructure  will  be  slow  to  develop  in 
the  decentralized  environment,  and  it  will  tend  to  be  inconsistent  (and 
expensive)  at  best. 

The  central  IS  department's  leadership  in  developing  an  information 
architecture  for  the  next  century  seems  to  be  essential  if  applications 
selection  and  infrastructure  changes  are  to  proceed  on  a  planned  basis. 
Actual  application  selection  has  not  yet  taken  place,  but  it  is  anticipated 
that  major  applications  that  are  downsized  to  more  cost-effective  plat- 
forms will  remain  the  responsibility  of  the  data  center  for  purposes  of 
operational  and  data  base  management. 

d.  Platform  and  Architecture  Selection 

IS  management  is  maintaining  a  position  of  leadership  in  platform  and 
architecture  selection  for  the  "architected"  (or  centralized)  side  of  down- 
sizing. It  is  anticipated  that  RISC  file  servers  coupled  with  the  mainframe 
data  bases  will  be  housed  in  the  central  data  center,  and  the  IS  department 
has  already  standardized  on  Macintoshes.  However,  a  variety  of  equip- 
ment will  continue  to  be  installed  over  the  greater  campus  network,  and 
the  central  IS  function  recognizes  that  coexistence  (and  various  levels  of 
integration)  will  remain  a  way  of  life  for  the  foreseeable  future. 
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e.  Cost  Justification 

It  was  stated  that  the  management  direction  toward  decentralization  and 
downsizing  has  not  been  prompted  by  any  thorough  analysis  or  cost 
justification.  "It  wasn't  even  a  seat  of  the  pants  judgment,  it  was  more  like 
a  gut  reaction..."  was  the  way  one  interviewee  described  the  decision  to 
move  toward  downsizing  and  client/server  architecture.  There  is  currently 
no  unanimous  agreement  that  downsizing  will  be  cost  justified;  it  has  been 
prompted  by  "...what  some  people  have  read  in  the  trade  press." 

IS,  confronted  with  the  "dispersal"  of  personnel  resources  to  user  depart- 
ments, and  sensitive  to  the  technological  innovations  that  are  shaping 
information  systems  infrastructures  of  the  1990s,  decided  that  it  was 
necessary  to  define  a  long-range  information  architecture  for  the  univer- 
sity— something  that  would  extend  well  beyond  the  year  2000. 

2.  Implementation 

Recognizing  the  complexity  of  developing  the  long-range  information 
architecture,  the  IS  department  was  prepared  to  spend  a  substantial  amount 
of  money  for  consulting  services  to  help  in  the  initial  definition.  In  late 
1990,  a  comprehensive  RFP  (which  emphasized  the  existing  IS  infrastruc- 
ture) was  prepared  and  two  proposals  were  received  from  major  consulting 
firms.  A  year  ago,  it  was  determined  that  neither  proposal  demonstrated 
that  such  consulting  would  be  of  substantive  assistance  in  defining  and 
implementing  the  information  architecture.  (And  the  price  tag  for  any 
political  assistance  that  might  have  been  afforded  by  having  an  outside 
consultant  involved  was  too  high.) 

Therefore,  it  was  decided  that  the  design  and  development  of  the  interim 
information  systems  architecture  would  be  accomplished  employing 
university  resources  under  the  direction  of  the  "CIO."  One  of  the  primary 
objectives  will  be  to  establish  policies  and  standards  (even  though  past 
experience  indicates  enforcement  will  be  difficult).  Preliminary  to  the 
establishment  of  a  permanent  implementation  team,  various  task  forces 
were  established  to  address  such  issues  as  migration,  interoperabihty,  and 
cost  and  funding.  In  this  report,  INPUT  will  concentrate  on  the  work  of 
the  Cost  and  Funding  Task  Force. 

3.  The  Cost  and  Funding  Task  Force 
a.  Purpose  of  the  Task  Force 

The  purpose  of  the  Cost  and  Funding  Task  Force  was  to  examine  and 
identify  appropriate  methodologies,  processes  and  resources  to  determine 
the  financial  feasibility  and  advantages  to  the  institution  of  moving  to  a 
new  information  systems  architecture.  The  task  force  was  informed  that 
the  primary  financial  goal  of  new  architecture  will  be  to  facilitate  the 
purchase  and  installation  of  off-the-shelf  commercial  software  applica- 
tions that  have  the  following  characteristics  and  benefits: 
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•  The  "applications"  will  reside  on  either  distributed  (LAN)  or  mainframe 
(central)  platforms,  and  will  be  interoperable. 

•  They  will  have  the  benefit  of  avoiding  "cosdy  in-house  application 
development  and  maintenance," 

•  They  will  provide  the  university  staff  with  improved  access  to  "institu- 
tional data." 

This  statement  of  purpose  to  the  task  force  provides  insight  into  the  moti- 
vation behind  the  management  directives  to  "disperse"  IS  personnel  to 
user  departments,  and  to  downsize  to  a  client/server  environment.  It  is 
obvious  that  management  has  not  been  pleased  with  the  cost  of  applica- 
tions development,  and  users  have  not  been  pleased  with  access  to  institu- 
tional data  resources. 

The  task  force,  having  been  charged  with  the  responsibility  for  doing  a 
preliminary  cost/benefit  analysis  of  moving  to  the  new  architecture,  made 
some  "important  and  fundamental  assumptions"  during  the  course  of  its 
working  sessions. 

b.  Assumptions 

The  following  are  the  assumptions  of  the  Cost  and  Funding  Task  Force, 
with  input's  comments  as  appropriate: 

•  A  "data  warehouse"  will  be  created  within  the  institution,  and  it  will  be 
managed  by  the  central  data  center.  (This  is  a  necessary  and  convenient 
assumption  for  the  Cost  and  Funding  Task  Force  that  leaves  open  the 
question  of  the  existing  in-house-developed  DBMS  and  its  data  bases. 
Presumably  the  other  task  forces  will  have  to  determine  whether,  how, 
and  when  to  shift  data  bases.) 

•  Local  hardware  (such  as  workstations  and  printers)  will  be  the  responsi- 
bility of  the  individual  departments  and  will  comply  with  institutional 
policy  on  supported  platforms.  (The  data  center  currentiy  provides 
terminal  support  for  a  wide  variety  of  platforms  and  devices.) 

•  LANs  will  be  a  responsibility  of  the  departments  in  terms  of  both  cost 
and  technical  support.  (INPUT  doubts  whether  the  technical  support 
portion  of  this  assumption  will  survive  review  and/or  actual  practice — 
the  user  departments  have  been  too  accustomed  to  excellent  campus 
networking  support.) 

•  An  institutional  policy  will  be  enacted  to  limit  the  number  of  hardware/ 
software  platforms  for  which  application  tools  will  be  developed. 

•  Data  integrity,  security  and  authentication  will  be  the  responsibility  of 
the  centralized  data  center  and  network  communications  services. 
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c.  The  Cost  Model 

Based  on  the  above  assumptions,  the  task  force  developed  a  comprehen- 
sive cost  matrix  (shown  in  Exhibit  IV- 1)  that  compared  a  campus  client/ 
server  architecture  with  the  existing  central  mainframe  environment. 


EXHIBIT  IV-1 


Downsizing  Cost  Factors 


Cost  Factors 

Data  Center 

Network 
Services 

Application 
Custodian 

End  User 

Application  Support 

Development 

Neutral 

Neutral 

Minus  (1 ) 

Neutral 

Maintenance 

Neutral 

Neutral 

Minus  (2) 

Neutral 

Documentation 

Neutral  (3) 

Plus 

Neutral 

Neutral 

Training 

Neutral 

Neutral 

Pius 

Neutral 

Hardware 

— — — — — — 

LANs 

Neutral 

— — - — ™— 
Neutral 

Plus  (4) 

Workstations 

Neutral  (6) 

Neutral 

Neutral 

Plus  (5) 

Servers 

Minus  (7) 

Neutral 

Neutral 

Neutral 

NetworK  bacKDone 

Neutral 

rlUS  (o) 

Neutral 

Neutral 

Environmentals 

Minus 

Neutral 

Neutral 

Plus 

Systems  Support 

Data  Quality 

Plus  (10) 

Plus  (9) 

Plus 

Neutral 

Standards 

Minus 

Minus 

Minus 

Minus 

Systems  Software 

Plus  (11) 

Neutral 

Plus 

Neutral 

Staffing 

Staffing  Levels 

Neutral 

Plus 

Minus 

Minus 

Local  Expertise 

Neutral 

Neutral 

Neutral 

Plus 

Transition  Costs 

Plus  (12) 

Plus 

Plus 

Plus 
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The  various  cells  in  the  matrix  indicate  whether  the  Cost  and  Funding 
Task  Force  felt  that  a  client/server  architecture  would  result  in  increased 
(plus),  decreased  (minus),  or  approximately  the  same  (neutral)  base  expen- 
ditures than  the  existing  mainframe-oriented  architecture. 

These  judgments  obviously  depend  upon  the  task  group's  knowledge  of 
current  expenditures  and  their  expectations  of  the  client/server  architec- 
ture. However,  they  are  also  heavily  dependent  upon  individual  percep- 
tions of  the  value  of  current  information  systems  and  services.  For  that 
reason,  it  is  not  surprising  that  the  five  members  of  the  Cost  and  Funding 
Task  Force  did  not  always  see  eye  to  eye  on  even  these  rough  estimates  of 
the  cost  benefits  of  downsizing.  These  initial  evaluations  may  be  viewed 
as  the  development  of  a  more  detailed  set  of  assumptions  that  will  require 
continuing  refinement  as  the  process  of  developing  an  information  sys- 
tems architecture  proceeds. 

The  following  "notes"  (or  qualifications)  were  provided  by  the  task  force 
for  the  most  "significant  cost  components,"  and  they  illustrate  the  prelimi- 
nary and  tentative  nature  of  the  cost/benefit  analysis. 

(1)  The  Cost  and  Funding  Task  Force  was  told  that  one  of  the  primary 
financial  goals  of  the  new  information  systems  architecture  was  to 
"avoid  costly  in-house  development,"  and  the  task  force  dutifully 
indicates  that  applications  development  cost  will  go  down.  However, 
the  following  is  a  summary  of  the  lengthy  note  of  qualification  that  was 
attached  to  the  matrix  (on  the  preliminary  report  of  the  task  force)  with 
input's  comments  as  appropriate. 

•  "The  marketplace  will  be  providing  a  much  richer  environment  of  tools 
to  assist  the  full  range  of  the  development  process,  and  once  the  learning 
curve  problems  are  met,  we  will  find  that  the  development  process  will 
be  cheaper  and  faster."  (This  is  obviously  an  assumption  that  CASE, 
GUIs,  packaged  applications,  etc.  will  be  superior  to  the  current  devel- 
opment environment  at  the  university.) 

•  "This  means  that  in  the  near  term  (2-3  years)  we  will  be  climbing  a 
learning  curve,  and  applications  development  tools  will  not  yet  be  able 
to  overcome  the  lost  productivity..." 

•  "Since  some  of  these  same  tools  could  be  used... whether  the  system  is 
mainframe  or  client/server... we  will  not  increase  our  productivity  over 
the  mainframe  development  environment."  (Downsizing  and  client/ 
server  architecture  may  not  be  directly  related  to  achieving  the  goal  of 
more  cost-effective  systems  development.) 
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•  "We  will  have  whole  new  areas  of  security,  integrity,  recoverability, 
language  standards... which  we  will  need  to  learn,  develop  and  manage 
before  turning  the  'benefits'  comer."  (In  other  words,  don't  hold  your 
breath  waiting  for  the  benefits  of  downsizing  to  materialize.) 

(2)  The  task  force  was  more  optimistic  about  the  benefits  associ- 
ated with  applications  maintenance  in  the  client/server  environ- 
ment, but  even  here  it  is  qualified  by  stating  that  this  will  be  due  to 
the  fact  that  "...we  will  not  be  investing  in  this  on  the  mainframe 
side..."  Then,  it  was  stated  that  expert  systems  "...will  also  start  to 
come  into  play  for  use  in  maintenance.. .over  time."  (Systems 
maintenance- — both  hardware  and  software — has  been  a  designated 
target  of  opportunity  for  artificial  intelligence  for  a  long  time,  and 
it  is  input's  considered  opinion  that  applications  maintenance  in 
a  decentralized  environment  will  actually  become  more  complex. 
In  fact,  this  has  actually  been  confirmed  to  a  certain  degree  be- 
cause the  IS  personnel  that  have  been  "dispersed"  to  user  depart- 
ments have  less  time  available  for  development  work.) 

(3)  The  reduced  costs  of  documentation  for  internally  developed 
systems  software  (DBMS,  electronic  mail,  calendaring,  etc.)  will 
be  offset  by  continuing  (and  perhaps  increased)  costs  for  docu- 
menting new  services,  standards  and  preferred  programming 
practices  in  the  client/server  environment. 

(4)  Since  an  initial  assumption  was  made  that  users  would  bear  the 
expense  of  LANs  (including  technical  support),  it  is  only  natural  that 
there  will  be  an  increased  cost  to  end  users.  The  task  force  notes  that: 

•  "As  departments  move  to  the  new  client/server  architecture,  there  will 
be  heavy  demands  for  installing  more  sophisticated  local-area  networks 
to  take  advantage  of  the  productivity  improvements  of  the  new  architec- 
ture." (It  should  be  noted  that  end-user  staffing  levels  are  being  lowered 
in  anticipation  of  this  improvement  in  productivity,  but  the  anticipated — 
and  promised — white-collar  productivity  gains  associated  with  personal 
computers  failed  to  materialize  in  the  1980s.) 

•  "This  (the  user  investment  in  new  LAN  technologies)  will  mean  in- 
creased cost  for  network  hardware,  software,  and  the  expertise  to  sup- 
port the  networked  environment."  (See  the  note  on  this  item  under  the 
Assumptions  section  above.  INPUT  does  not  know  whether  the  central 
IS  function  is  playing  political  games  here,  but  when  asked  about  vendor 
support  for  the  emerging  downsizing  technologies,  the  reply  was:  "It 
stinks."  It  is  possible  that  the  central  function  wants  to  give  end  users  a 
taste  of  reality.) 

(5)  The  task  force  notes  that  there  will  be  a  significant  increase  in 
costs  to  the  institution  as  the  result  of  upgrading  end-user  worksta- 
tions in  order  to  "...be  able  to  handle  the  processing  and  data  ma- 
nipulation requirements  of  the  client/server  environment."  An 
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estimate  is  given  that  the  minimum  configuration  (for  example,  for  a 
Macintosh  Elci)  will  cost  "about  $4,000  per  station"  and  when  that  is 
totaled  up  for  the  institution  it  may  represent  the  highest  increased 
cost  associated  with  the  new  information  architecture.  (Just  as 
systems  software  has  been  more  than  up  to  the  task  of  "keeping  the 
mainframe  busy,"  count  on  the  operating  systems  needed  to  support 
image  processing,  GUIs  and  multimedia  to  be  able  to  gobble  all 
those  cheap  MIPS  we  keep  hearing  about.) 

(6)  Even  though  the  cost  of  workstations  in  the  central  IS  function 
(the  Data  Center)  is  projected  to  remain  essentially  the  same,  the 
task  force  saw  fit  to  add  a  note  stating  that  the  "increases  in  costs 
will  occur"  just  "as  with  all  other  departments  and  offices."  (The 
only  reason  we  can  think  of  for  the  "neutral"  rating  is  that  recent 
upgrading  of  workstations  in  the  IS  function  probably  means  they 
will  not  have  to  upgrade  in  the  near  term,  and  they  have  probably 
always  stayed  ahead  of  the  end  users.  Therefore,  client/server 
won't  make  that  much  difference.) 

(7)  Here  is  the  way  the  decreased  cost  of  data  center  servers  is 
rationalized  (as  well  as  qualified).  Follow  this  one  closely — it  is  at 
the  heart  of  the  cost  justification  for  downsizing  from  mainframes. 

•  The  note  starts  by  stating  that  there  will  be  "a  significant  increase  in  the 
costs  of  server  hardware."  (Remember  that  despite  the  best  efforts  to 
downsize,  the  mainframe  will  probably  go  through  two  major  upgrades, 
and  the  mainframe  is  viewed  as  a  central  server  in  the  new  architecture.) 

•  "Many  functions  now  bundled  on  the  mainframe  will  be  provided  on 
servers. ..these  servers  will  need  to  be  purchased."  (While  the  mainframe 
stays  installed.) 

•  "This  cost  increase  will  be  partially  offset  by  a  gradual  decrease  in  the 
cost  of  mainframe  hardware."  ("Partially  offset"  and  "gradual  decrease" 
certainly  qualify  the  hardware  cost  benefits  that  are  being  anticipated 
from  downsizing.) 

•  Then,  finally,  it  is  stated  that:  "As  the  mainframe's  role  decreases... the 
size  (and  therefore  cost)  should  decrease  also."  (One  gets  the  impres- 
sion that  the  task  force  has  some  severe  reservations  about  the  ability  to 
decrease  hardware  costs  by  installing  the  client/server  architecture — at 
least  for  a  number  of  years.  To  support  this  "minus"  evaluation,  one 
must  cenainly  take  a  long-range  view.) 

(8)  The  university  has  already  spent  millions  of  dollars  on  the 
campus  network  and  has  gone  through  a  period  of  some  embar- 
rassment because  maintenance  costs  were  not  properly  estimated 
in  the  original  cost  justification.  However,  the  backbone  network 
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is  certainly  more  advanced  than  most  that  are  currently  installed 
among  even  large  commercial  users.  The  task  force  has  con- 
cluded that: 

•  "...more  large  packets  of  data  will  travel  over  the  network,  requiring 
greater  bandwidth." 

•  "Under  the  client/server  model,  the  network  will  have  to  become  a 
production  level  system  with  increased  reliability,  availability  and 
support." 

•  Then,  because  the  network  is  critical  to  the  client/server  environment, 
"...we  will  have  to  make  increased  investments  in  training,  documenta- 
tion and  consulting  support."  (The  net  result  of  all  this  is  that  even  with 
a  relatively  advanced  communications  infrastructure,  client/server 
computing  requires  additional  investment.) 

(9)  The  network  will  be  required  to  provide  authentication  and  security 
services  in  addition  to  those  currendy  provided  on  the  mainframe  sys- 
tem. This  will  require  a  network  or  "data  warehouse,"  "security  serv- 
ers," and  a  full  level  of  maintenance  and  support  by  network  services. 
(Remember,  the  assumption  was  made  that  the  data  center  and  network 
services  would  share  responsibility  for  data  quaUty  in  the  client/server 
environment.) 

(10)  The  task  force  notes  that  to  maintain  data  quality  will  require  a 
"major  increase  in  cost"  for  the  data  center  because  "distributing  data  will 
increase  administrative  costs  of  managing  the  data  and  the  tools  to  access 
the  data."  (While  it  wasn't  specifically  noted,  the  university  will  probably 
find  itself  with  all  the  complexity — and  expense — that  is  characteristic  of 
many  large  IBM  mainframe  shops  that  have  a  complex  IMS/CICS/DB2 
type  of  DBMS  environment.  Certainly  the  in-house-developed  DBMS 
isn't  going  away  overnight,  and  the  university  has  already  installed  DB2  in 
anticipation  of  needing  a  relational  DBMS  at  the  mainframe  level.  The 
problems  of  data  base  management  increase  dramatically  from  an  environ- 
ment where  use  of  a  single,  centralized  DBMS  was  the  foundation  of  all 
commercial  development  work.) 

(11)  Systems  software  will  represent  a  "significant  increase  in 
costs"  to  the  data  center  even  if  the  mainframe  doesn't  grow.  This 
problem  is  compounded  by  the  fact  that  the  university  has  done  so 
much  of  its  own  systems  programming  work.  Now  the  university 
must  get  mainframe  software  licenses  to  support  the  client/server 
environment  at  all  three  levels  (mainframe  server,  distributed 
server,  and  client). 
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(12)  That  brings  us  to  the  question  of  transition  costs.  Here  is  what 
the  task  force  had  to  say  about  that  subject:  "Major  institutional 
cost  (one-time,  although  for  many  years);  we  will  need  to  support 
and  operate  in  a  dual  architecture  environment— both  mainframe 
and  client/server— for  many  years."  (And  it  should  be  pointed  out 
that  during  those  "many  years"  there  will  be  increased  costs  across 
the  board.) 

The  university  has  already  determined  that  there  will  never  be  payback  on 
converting  certain  applications  because  they  will  not  endure  long  enough 
to  pay  back  their  transition  costs.  On  the  other  hand,  it  is  extremely 
expensive  to  be  caught  halfway  between  old  and  new  information  archi- 
tectures. We  do  not  envy  CIOs  who  are  confronted  with  comparable 
problems,  but  they  are  certainly  better  off  than  those  who  are  not  aware 
that  the  problems  exist. 

What  do  all  of  the  pluses  and  minuses  mean? 

That  is  the  question  raised  by  the  director  responsible  for  developing  the 
university's  long-range  information  architecture.  It  is  a  good  question, 
and  it  is  obvious  that  the  work  of  the  Cost  and  Funding  Task  Force  (or  the 
follow-on  permanent  team)  is  far  from  complete.  However,  the  Task 
Force's  report  is  an  extremely  important  and  useful  document. 

•  It  provides  a  way  of  thinking  about  the  broader  cost  ramifications  of 
downsizing  that  go  well  beyond  the  relative  cost  of  MIPS  on  a  RISC 
workstation  and  an  IBM  mainframe. 

•  It  also  isolates  critical  factors  that  must  be  analyzed  and  played  off 
against  each  other  to  determine  the  net  impact  of  downsizing.  For 
example: 

-  Will  the  decreases  in  application  development  costs  actually  be 
realized?  Or  will  those  involved  merely  be  confronted  with  a  replay 
of  the  4GL  saga  on  a  new  platform  and  in  a  new  environment? 

-  Even  if  these  benefits  do  materialize,  will  they  be  more  than  offset  by 
the  increased  costs  necessary  to  maintain  data  quality?  Or  will  data 
base  integrity  be  sacrificed  because  of  quick-and-dirty  appUcation 
development? 

-  Will  transition  costs  become  a  critical  drain  on  both  human  and 
financial  resources,  and  adversely  impact  the  necessary  maintenance 
of  mission-critical  applications?  Or,  worse  yet,  will  we  get  90%  of 
the  way  through  the  distribution  of  data  bases  only  to  find  that  the  last 
10%  seem  to  require  maintenance  of  full  corporate  data  bases  stretch- 
ing seamlessly  into  perpetuity? 
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INPUT  will  assess  the  critical  factors  and  provide  a  framework  for  balanc- 
ing of  pluses  and  minuses  when  it  analyzes  the  case  studies  and  simplifies 
the  cost  model  later  in  this  report.  However,  the  Cost  and  Funding  Task 
Force  provided  ESIPUT  with  additional  value  by  recommending  some 
strategies  for  implementing  the  move  to  a  downsized  client/server  archi= 
tecture. 

d.  Recommended  Strategies 

Questions  involving  funding  and  cost  recovery  become  prominent  as  soon 
as  information  technology  is  shared.  These  questions  were  raised  starting 
with  simple  timesharing  systems;  they  led  to  extensive  system  manage- 
ment facilities  for  purposes  of  billing,  and  capacity  and  performance 
planning  on  mainframe  computers;  and  their  importance  extends  to  the 
"production  network"  that  will  result  from  the  new  information  systems 
architecture  being  implemented  at  the  case  study  university. 

The  recommended  strategies  from  the  Cost  and  Funding  Task  Force 
address  these  issues,  and  this  is  especially  commendable,  because  many 
otherwise  responsible  IS  managers  feel  that  computer  technology  is 
becoming  so  cheap  that  it  isn't  worthwhile  to  worry  too  much  about  cost 
justification  or  accounting  for  its  use. 

The  following  is  a  brief  summary  of  the  recommended  strategies: 

•  Existing  workstations  will  only  be  replaced  at  the  end  of  their  useful  life 
and  not  by  a  mass  upgrade.  Where  more  powerful  hardware  is  required 
by  a  client/server  application,  the  cost  should  be  included  in  the  develop- 
ment costs.  (This  will  tend  to  reduce  application  development  cost 
savings,  but  it  will  be  a  more  accurate  assessment  of  the  true  costs.) 

•  It  is  also  recommended  that  staff  productivity  savings  be  applied  to  fund 
departmental  hardware  and  LAN  costs.  (This  will  bootstrap  the  imple- 
mentation of  the  new  client/server  architecture,  but  it  also  implies 
specific  cost  justification.) 

•  It  is  recommended  that  applications  built  on  the  in-house  DBMS  be 
replaced  only  when  there  is  a  business  purpose  for  doing  so;  but  new 
applications  should  be  developed  in  client/server  architecture.  (Presum- 
ably, the  in-house  DBMS  could  be  employed  for  client/server  applica- 
tions if  it  is  deemed  appropriate.  Certainly  some  type  of  pair-wise 
connectivity  will  be  required  between  the  in-house  DBMS  and  many 
client/server  applications.) 

•  Include  incremental  costs  of  the  "production  network"  in  application 
development  projects  for  the  purpose  of  network  funding. 
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•  Funding  sources  should  be  interchangeable  across  the  mainframe  and 
client/server  architectures,  and  the  source  of  funds  should  not  become  an 
issue  when  deciding  which  architecture  to  use  for  developing  a  new 
system.  (File  and  data  base  servers  supplied  on  the  network  should  be 
reasonably  transparent  to  systems  developers,  but  presumably  some 
LAN  servers  could  be  the  responsibility  of  the  user  department) 

•  Cost  recovery  mechanisms  should  be  consistent  between  the  two  archi- 
tectures, and  capacity  of  platform  should  not  be  a  cost  consideration 
when  developing  client/server  applications.  (In  other  words,  the  user 
should  not  be  concerned  about  where  data  being  managed  by  the  data 
center  resides.) 

One  thought  expressed  about  cost  recovery  that  did  not  appear  in  the  task 
force  report  is  especially  intriguing.  Rather  than  use  a  conventional  billing 
algorithm,  it  has  been  suggested  that  clients  be  billed  primarily  on  the 
basis  of  data  storage,  data  access,  and  data  distribution.  (Essentially,  de- 
emphasizing  processing  cycles  and  emphasizing  the  value  added  by  the 
data  base  server  in  terms  of  data  base  integrity,  synchronization,  and 
security.) 

Using  a  broad  definition  of  data  (anything  stored  in  a  computer),  and 
properly  constructed,  such  a  billing  scheme  would  have  many  advantages 
in  encouraging  proper  data  base  design  and  use  of  server  resources.  In 
addition,  the  end  result  would  be  to  assign  value  to  data  and  link  it  closely 
with  its  end  use.  This  would  go  a  long  way  toward  identifying,  classify- 
ing, and  managing  data  in  our  computers;  and  would  provide  a  solid 
foundation  for  identifying  valuable  information  that  has  been  lost  among 
data. 

In  the  other  downsizing  case  studies,  INPUT  will  apply  the  cost  model  to 
isolate  the  issues  with  which  other  organizations  are  struggling. 


B  

Case  Study  #2 — Rightsizing  the  Information  Architecture 

1.  Background 

This  case  study  company  is  a  major  railroad  that: 

•  Could  be  considered  IBM's  first  customer  because  it  tested  early  punch- 
card  equipment  for  IBM's  predecessor 

•  Had  a  communications  network  before  there  was  a  telephone  company, 
and  installed  what  was  once  the  world's  largest  private  microwave 
network 
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•  At  one  point  about  thirty  years  ago,  had  a  radical  computer  group  in  the 
operating  department  that  decided  to  develop  all  of  its  own  systems 
software  with  the  following  results: 

-  The  human  and  machine  time  devoted  to  program  development  on  an 
IBM  mainframe  was  reduced  by  more  than  an  order  of  magnitude. 

-  The  operating  department  was  able  to  select  its  own  mainframe 
computer  without  regard  for  vendor  supplied  systems  software  and 
support;  but  when  it  did  so,  the  Brand  X  computer  vendor  had  serious 
hardware  problems  and  couldn't  deliver  on  time. 

-  It  then  prompdy  installed  an  IBM  mainframe  of  radically  different 
architecture  from  the  one  it  had  been  using  without  the  "benefit"  of 
any  IBM  systems  software  or  systems  engineering  support. 

•  Specified  and  installed  the  first  IBM  computer  terminals  before  they 
were  an  announced  product. 

•  Used  high-speed  xerography  for  transmission  of  paper  documents  and 
data  capture  in  the  1960s. 

•  Went  heavily  into  distributed  processing  (downsizing)  in  the  1970s  by 
installing  an  extensive  network  of  Data  General  minicomputers. 

•  Enhanced  the  network  with  personal  computers  in  the  1980s. 

•  Is  now  installing  Tandem  image  processing  systems  that  will  eventually 
change  the  information  architecture  of  the  company  once  again. 

In  other  words,  the  railroad  has  generally  been  on  the  leading  edge  of 
information  technology  innovation. 

However,  management  at  the  railroad  feels  that  it  is  trapped  on  IBM 
mainframes  with  expensive,  proprietary  systems  software;  and  it  has 
difficulty  understanding  how  the  company  ever  got  itself  in  this  unfortu- 
nate position. 

2.  The  Mainframe  Trap 

What  management  doesn't  understand  is  that  the  railroad  got  where  it  is 
today  because  the  IS  depanment  decided  to  do  everything  "right."  It  was 
decided  in  the  mid-1960s  that  it  was  ridiculous  to  develop  systems  soft- 
ware, when  it  was  available  "free"  from  IBM.  Then  the  company  stan- 
dardized on  COBOL,  which  was  supposed  to  solve  ease-of-use  and  port- 
ability problems  for  all  time.  With  programs  written  in  English  language, 
executives  were  going  to  be  able  to  read  them  and  fmd  out  what  was  going 
on  in  the  IS  department;  and,  by  having  a  common  business-oriented 
language  supported  by  all  vendors,  users  would  become  vendor  indepen- 
dent. 
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What  seemed  like  a  good  idea  at  the  time  obviously  didn't  turn  out  that 
way,  or  the  company  wouldn't  be  concerned  about  the  expense  of  IBM 
systems  software,  and  executives  wouldn't  have  to  be  asking  the  IS  de- 
partment why  the  "investment"  in  COBOL  programs  is  the  primary  reason 
the  company  will  remain  trapped  on  mainframes  for  the  foreseeable 
future. 

The  early  expectations  for  COBOL  may  seem  naive  now,  but  for  those 
who  have  been  around  for  awhile,  there  is  striking  similarity  to  current 
UNIX  enthusiasm — including  the  strong  support  from  the  Department  of 
Defense. 

The  current  VP  of  IS  at  the  railroad  was  a  young  computer  engineer  in  the 
maverick  group  that  believed  in  developing  its  own  systems  software,  so 
he  saw  the  mainframe  software  trap  being  baited  and  sprung.  He  has 
made  every  effort  to  "rightsize"  independently  of  the  direction  set  by  IBM, 
and  he  has  employed  competitive  hardware  and  software  over  the  years, 
but  he  fmds  himself  and  his  company  fumly  locked  into  IBM's  propri- 
etary systems  software. 

a.  Systems  Software  Is  No  Longer  "Free" 

The  factors  prompting  discontent  with  mainframe  technology  on  the 
railroad  are  specifically  related  to  the  expense  of  mainframe  systems 
software.  The  cost  of  outside  software  is  currently  about  $3  million  a  year 
and  equally  split  between  IBM  and  other  vendors.  The  frustration  with 
software  expense  manifested  itself  during  INPUT'S  interview  with  the  VP 
of  IS,  and  it  arises  from  several  sources. 

•  The  document-handling  software  for  the  Tandem  image  processing 
system  represents  a  continuing  expense,  and  it  was  stated  that  the  only 
solution  might  be  to  "get  the  source  code  and  maintain  it  ourselves." 

•  A  mainframe  upgrade  from  a  Model  400  to  Model  600  resulted  in  the 
cost  of  mainframe  systems  software  increasing  enough  to  become  a 
topic  for  management  discussion.  The  VP  of  IS  still  remembers  the 
pressure  IBM  applied  to  his  management  to  accept  its  "free"  systems 
software  many  years  ago  when  he  was  still  a  young  systems  program- 
mer. He  also  knows  how  much  that  small,  highly  skilled  team  accom- 
plished, and  this  makes  it  all  the  more  difficult  to  rationalize  the  current 
systems  software  trap. 

-  He  finds  it  is  extremely  difficult  to  explain  to  his  management  why 
the  price  for  the  same  software  keeps  escalating  every  time  they 
upgrade  their  hardware. 
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-  Then,  senior  management  (and  even  the  board  of  directors)  wants  to 
know  how  they  ever  got  themselves  in  a  position  of  not  having  alter- 
native sources  of  supply  for  IBM  systems  software.  When  he  tries  to 
explain  how  that  happened  "they  just  don't  understand." 

-  He  stated  that  he  can  understand  IBM's  position  because  "they  are  in 
business,  too" — but  he  wishes  he  had  an  alternative  to  IBM  systems 
software.  He  thought  at  one  time  that  EDS  and  Hitachi  might  come 
up  with  an  alternative  to  IBM  operating  systems,  but  then  he  remem- 
bered the  setdement  of  IBM's  suit  against  Fujitsu  and  realized  that 
there  isn't  much  possibility  of  any  real  alternative  to  IBM  operating 
systems  becoming  available. 

-  He  mused  that  perhaps  they  were  right  30  years  ago  when  they  devel- 
oped all  their  own  systems  software  in  the  operating  department,  but  it 
seems  obvious  that  this  is  not  a  viable  solution  to  the  current  problem. 
(The  systems  software  trap  was  baited  with  "free"  software  30  years 
ago  and  once  the  bait  was  taken  and  the  unbundling  trap  was  sprung, 
there  has  been  no  escaping  for  IBM  mainframe  customers.) 

•  Over  the  years,  the  railroad  attempted  to  maintain  as  much  freedom  as  it 
could,  but  that  hasn't  helped  very  much  either.  The  railroad  installed 
EDMS  in  lieu  of  IMS  when  they  installed  a  DBMS,  and  now  that  repre- 
sents a  significant  portion  of  the  $1.5  million  a  year  of  non-IBM  soft- 
ware expense. 

It  all  adds  up  to  the  fact  that  mainframe  systems  software  (which  was 
designed  to  keep  mainframes  busy)  is  now  expensive  enough  to  attract  the 
attention  of  senior  management.  One  of  the  directors  of  the  railroad  is 
president  of  another  organization  that  discarded  its  mainframe  in  favor  of 
IBM  AS/400s,  and  he  mentioned  that  this  downsizing  effort  is  working  out 
quite  well.  When  this  level  of  computer  literacy  sneaks  into  the  board 
room,  IS  management  is  under  constant  pressure  to  consider  alternatives 
to  perceived  problems  such  as  mainframe  software  expense.  Published 
information  concerning  downsizing  and  open  systems  are  the  stones  being 
thrown  at  the  mainframe  glass  house — what  has  been  going  on  in  there  is 
becoming  increasingly  apparent. 

The  railroad  isn't  thinking  so  much  about  downsizing  as  a  strategy;  it  has 
been  attempting  to  use  computer  technology  at  proper  levels  for  years.  It 
is  thinking  about  how  to  get  out  of  the  mainframe  software  trap,  and  that  is 
not  soins  to  be  easv. 

b.  The  Nature  of  the  Trap 

One  of  the  primar\'  factors  inhibiting  the  railroad  from  downsizing  is  its 
30-year  "investment"  in  COBOL  programming.  The  railroad's  initial 
decision  to  go  COBOL  was  strongly  influenced  by  some  of  those  in  the  IS 
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management  hierarchy  who  had  experience  in  the  Air  Force,  which  was 
then  one  of  the  strongest  COBOL  proponents.  They  honestly  believed  all 
of  the  wonderful  claims  that  were  being  made  for  COBOL  at  that  time. 

Unfortunately,  by  the  early  1980s,  a  major  government- sponsored  study 
was  projecting  that  because  of  ."..the  current  use  of  FORTRAN  and 
COBOL...the  U.S.  will  have  a  national  inventory  of  unstructured,  hard-to- 
maintain,  impossible-to-replace,  programs..."  threatening  to  confront  us 
with  a  ."..software  gap  more  serious  than  the  missile  gap  of  some  years 
ago."  [22]  Those  early  believers  in  COBOL,  such  as  the  railroad,  now 
find  themselves  in  precisely  that  position,  and  they  aren't  terribly  im- 
pressed when  the  Air  Force  and  other  govemment  agencies  start  making 
the  same  promises  for  UNIX  and  C. 

The  railroad  also  has  an  extensive  investment  in  EDMS.  It  was  expensive 
to  convert  to  a  DBMS  in  the  first  place.  One  respondent  to  an  INPUT 
research  project,  when  asked  about  the  cost  of  converting  to  a  DBMS, 
said,  "We  don't  know,  and  I  don't  think  we  want  to  know."  Now  these 
large  central  data  bases  are  in  place,  and  it  will  be  even  more  expensive  to 
convert  them  to  a  radically  new,  downsized  information  architecture.  In 
fact,  it  is  doubtful  whether  some  of  them  will  ever  be  converted— abol- 
ished maybe,  converted  no! 

The  factors  currently  inhibiting  downsizing  are  directly  related  to  the 
railroad's  actual  experience  with  transferring  responsibility  for  data 
quality  to  operating  management.  This  experience  is  worth  reviewing. 

3.  Information  Architecture  and  Data  Quality 

Railroading  has  always  been  an  information-intensive  business.  Railroads 
must  account  for  their  use  of  equipment  from  other  railroads  and  private 
line  car  owners,  and  pay  for  the  use  of  these  cars  on  a  per  diem  or  mileage 
basis.  They  also  must  be  able  to  bill  shippers,  other  railroads,  and  for- 
warding agents  based  on  complex  rate  schedules  for  various  goods  and 
commodities  that  are  shipped  over  their  lines.  And — of  primary  impor- 
tance— they  must  be  able  to  distribute  equipment  and  track  shipments  in 
order  to  be  of  service  to  their  customers. 

The  subject  railroad  has  attempted  to  use  information  technology  to  gain 
competitive  advantage  by  providing  advanced  services  to  customers,  some 
of  whom  use  the  railroad  as  an  extension  of  their  assembly  lines  and  as  the 
replacement  for  parts  warehouses.  Success  depends  on  high-quality, 
timely  information  as  much  as  it  does  on  efficient  operation  of  the  railroad 
system.. 
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Over  the  years,  the  railroad  has  adopted  various  information  architectures 
depending  upon  the  availability  of  information  technology  and,  more 
importandy,  the  need  to  maintain  data  quality.  This  has  resulted  in  the 
cycles  of  centralization  and  decentralization  summarized  in  Exhibit  IV-2. 


EXHIBIT  IV-2 
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a.  Early  Data  Processing — Centralized 

As  mentioned  earlier,  the  railroad  was  an  early  innovator  in  the  use  of  unit 
record  (punch-card)  equipment.  Paper  documents  arrived  at  a  central  data 
processing  facility  through  the  mail  (which  was  usually  delivered  by 
train),  and  data  was  entered  (keypunched)  from  these  documents  and 
verified  under  close  supervision.  There  were  nearly  100  keypunch  opera- 
tors, and  each  card  contained  a  keypunch  operator  code  used  for  both 
qualitative  and  quantitative  performance  evaluation  of  the  individual 
operator. 

These  card  decks  represented  the  data  bases  of  the  centralized  data  pro- 
cessing facility,  which  until  the  advent  of  computers  consisted  of  punch- 
card  equipment  that  soned,  collated,  tabulated,  and  printed  all  necessary 
documents.  Card  decks  were  exchanged  with  other  railroads  to  account 
for  use  of  equipment. 

With  the  advent  of  computers  in  the  1950s,  card  images  were  transferred 
to  magnetic  tapes,  which  then  became  the  data  base,  and  computers  then 
sorted,  collated,  computed  and  printed  reports.  Magnetic  tapes  and/or  card 
decks  were  exchanged  with  other  railroads  depending  upon  their  current 
state  of  automation.  (EBCDIC  worked  just  fine  before  ASCII) 
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Since  it  was  after  the  fact,  this  highly  centralized  environment  resulted  in 
high-quality  but  not  very  timely  data  on  the  movement  of  equipment  and 
shipments  over  the  railroad.  It  was  essentially  a  computerized  unit  record 
operation — just  as  most  commercial  data  processing  operations  were  in 
the  1950s  and  1960s. 

be  Downsizing  Data  Entry  With  "Terminal  Typewriters" 

In  the  early  1960s,  a  maverick  group  of  computer  engineers  in  the  operat- 
ing department  justified  having  their  own  computer  for  the  control,  distri- 
bution and  reporting  of  car  movements  on  the  railroad.  In  order  to  distrib- 
ute equipment  (and  provide  customers  with  better  service)  it  was  neces- 
sary to  obtain  more  timely  data. 

The  "terminal  typewriters"  were  designed  and  named  with  great  care 
because  there  was  a  jurisdictional  dispute  between  railroad  clerks  and 
telegraphers  about  the  work  of  reporting  car  movement  information.  They 
were  installed  at  points  of  interchange  with  other  railroads  and  at  yards 
throughout  the  railroad  system.  They  were  relatively  crude  devices  that 
captured  essential  car  movement  information  as  a  yard  clerk  typed  a 
switch  list,  and  they  produced  a  punch  card  at  the  other  end.  The  cards 
then  entered  the  computerized  unit  record  operation  described  above. 

This  decentralized  operation  effectively  "downsized"  the  central  keypunch 
facility  where  operators  were  subjected  to  rigid  quality  control.  The  yard 
clerks,  on  the  other  hand,  worked  in  a  rough-and-tumble  environment 
where  the  primary  emphasis  was  on  putting  trains  together,  and  few  of 
them  even  had  the  advantage  of  being  touch  typists.  Several  problems 
developed  with  this  operation  almost  immediately: 

•  Having  one  bad  character  in  the  initial  or  car  number  of  a  freight  car  or  a 
station  number  doesn't  usually  matter  when  switching  cars  because  this 
is  close  enough  for  the  humans  involved.  However,  it  does  matter  to  a 
computer,  and  the  messy  switch  lists  of  the  past  had  to  be  improved  to 
"office  quality"  practically  overnight.  This  wasn't  easy,  especially  since 
some  of  the  yard  personnel  felt  that  the  computer  might  eventually 
eliminate  their  jobs. 

•  In  addition,  when  IBM  designed  the  terminal  typewriter,  it  did  not  see  fit 
to  distinguish  between  an  O  and  a  0  on  hard  copy  (a  problem  it  also  had 
on  some  of  its  printers  in  those  days).  Either  intentionally  or  uninten- 
tionally, Os  started  appearing  in  car  numbers  on  the  incoming  data. 
Even  though  the  computer  was  able  to  correct  these  mistakes  quite 
easily,  all  such  errors  were  reported  back  to  the  yards  for  correction, 
strengthening  the  opinion  that  the  computer  was  "watching"  what  was 
going  on.  This  worked  reasonably  well  because  fear  was  a  traditional 
means  of  motivation  in  railroad  yards. 
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With  continual  monitoring  and  management  pressure,  data  capture 
through  the  terminal  typewriters  proved  adequate  for  simple  car  move- 
ment information.  However,  the  operating  and  accounting  department 
computer  operations  were  integrated  shortiy  after  the  terminal  typewriters 
were  installed  in  1962,  and  the  more  detailed  waybill  information  required 
for  accounting  applications  proved  to  be  beyond  the  capacity  of  the  termi- 
nal typewriters  and  the  capability  of  the  yard  clerks.  It  was  simply  impos- 
sible to  maintain  data  quality  in  the  decentralized  environment. 

c.  Early  Image  Processing  and  Recentralization  of  Data  Entry 

In  1963,  it  was  decided  that  data  quality  could  be  improved  by 
recentralizing  the  data  entry  functions;  in  order  to  speed  the  process,  paper 
documents  were  transmitted  from  various  points  around  the  railroad  to  a 
central  data  entry  facility  using  high-speed  xerography.  This  was  techni- 
cally and  economically  made  possible  by  the  fact  that  the  railroad  had  by 
then  installed  the  world's  largest  private  microwave  network. 

Once  the  documents  were  received  at  the  central  location,  terminals 
attached  to  mainframes  could  be  employed  to  improve  the  data  entry 
operation.  Skilled  data  entry  personnel  and  centralized  quality  control 
could  now  be  accomplished  in  a  more  timely  fashion,  and  central  data 
bases  now  resided  on  direct  access  storage  devices.  The  days  of  running  a 
computerized  unit  record  shop  were  over. 

The  improved  information  flow  achieved  by  this  early  image  processing 
(or  at  least  transmission)  system  provided  timely  tracking  of  both  trains 
and  individual  shipments,  thus  improving  both  railroad  operations  and 
customer  service.  This  system  lasted  for  10  years — a  virtual  millennium 
by  today's  standards! 

de  Downsizing  with  Distributed  Processing 

By  1973,  advances  in  minicomputer  technology  made  it  economically  and 
technically  attractive  to  distribute  both  data  entry  and  operating  document 
preparation  back  out  into  the  yards  where  everyone  thought  it  belonged. 
The  railroad  proceeded  to  install  an  extensive  network  of  Data  General 
minicomputers  and  terminals,  and  operating  applications  were  downsized 
from  an  IBM  mainframe  to  those  platforms.  Some  of  the  same  data 
quality  problems  experienced  with  the  early  installation  of  the  terminal 
typewriters  reappeared. 

•  Information  sufficient  to  "run  the  railroad"  did  not  always  produce  data 
of  high  enough  quality  to  satisfy  accounting  and  customer  service 
requirements. 

•  A  central  "error  room"  was  established  at  the  central  computer  facility  to 
maintain  data  quality.  The  error  room  was  staffed  with  five  people  and 
their  job  was  to  identify  errors,  and  get  the  operating  department  to 
correct  them. 
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•  This  did  not  work  very  well  because  "running  the  railroad"  always  took 
priority  over  submitting  (or  resubmitting)  data  for  the  central  computer 
operation — regardless  of  whether  these  data  were  necessary  for  proper 
billing  or  customer  service.  IS  management  sincerely  felt  data  should  be 
captured  (and  corrected)  as  close  to  the  source  as  possible  even  though  it 
was  sympathetic  to  the  operating  problems  out  on  the  line  of  road. 

•  Although  IS  management  felt  the  "error  room"  was  expensive  and  not 
working  as  well  as  IS  would  have  liked,  it  continued  in  operation  until 
1983. 

During  this  period  of  downsizing,  the  central  mainframe  installation 
continued  to  grow.  The  railroad  became  a  major  user  of  IBM's  Mass 
Storage  System  (a  magnetic  cartridge-based,  low-cost  storage  system  that 
was  eventually  replaced  as  magnetic  disk  costs  continued  to  decrease)  in 
order  to  accommodate  growing  corporate  data  bases,  and  mainframe 
computers  continued  to  increase  in  size  to  support  "advances"  in  operating 
systems  and  data  base  management  technology. 

Cc  Personal  Computers  Appear 

When  personal  computers  were  just  beginning  to  penetrate  the  corporate 
environment  in  the  early  1980s,  INPUT  interviewed  the  railroad's  Vice 
President  of  IS,  and  his  position  was  that  he  would  release  "his  data"  to 
other  departments  if  management  told  him  to  do  so,  but  that  nothing 
would  get  into  his  data  bases  unless  processed  by  mainframe  applications. 
He  also  made  the  statement  that  printers  used  by  personal  computers 
should  be  "hardwired"  to  print  out  "The  IS  Department  Did  Not  Prepare 
this  Report."  One  can  sense  that  the  struggle  over  control  of  data  and  the 
responsibility  for  information  quality  had  already  been  joined  on  the 
railroad. 

Nonetheless,  at  about  this  time  (1983),  it  was  decided  that  the  error  room 
would  be  abolished  because  is  was  "expensive";  the  problems  of  data 
quality  (and  correction)  would  be  turned  over  to  the  transportation  depart- 
ment. This  was  justified  because  considerable  investment  was  being  made 
in  additional  processing  power  on  the  desktop,  and  with  "computer  lit- 
eracy" it  was  felt  that  users  should  become  more  sensitive  to  problems  of 
data  quality. 

During  the  research  for  this  downsizing  study,  INPUT  asked  the  VP  of  IS 
how  this  had  worked  out,  and  he  said:  "The  situation  just  got  a  lot  worse. 
They  (the  transportation  department)  just  don't  have  very  much  incentive 
to  maintain  data  quality.  I  guess  I  made  a  mistake." 

Perhaps  it  wasn't  a  mistake,  but  merely  an  accurate  representation  of 
reality.  INPUT'S  earlier  research  on  downsizing  showed  that  50%  of  IS 
management  believed  that  some  responsibility  for  "data  and/or  manage- 
ment information  quality"  would  be  transferred  to  users,  but  only  22%  of 
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vendor  management  agreed  with  this  assessment.  However,  when  this 
same  issue  was  slightly  restated  to  the  effect  that  data  base  management 
responsibility  would  be  transferred  to  users,  the  results  were  reversed,  with 
only  29%  of  IS  management  agreeing  compared  to  50%  of  vendor  man- 
agement. [2]  (The  important  issues  of  information  quality  and  data  base 
management  responsibiUty  will  be  analyzed  later.) 

f.  Downsizing,  Upsizing  and  Rightsizing 

What  was  referred  to  as  the  "last  upgrade"  of  the  distributed  minicomputer 
network  was  made  in  1984-1985.  The  feeling  that  minicomputer  architec- 
ture is  "dead"  (at  least  on  the  railroad)  is  due  to  development  of  PC  LANs, 
and  also  to  the  fact  that  the  fundamental  information  architecture  of  the 
railroad  is  being  re-engineered  once  again. 

•  Although  it  is  becoming  apparent  that  PC  LANs  in  a  client/server  archi- 
tecture are  more  cost  effective  for  many  of  the  functions  previously 
performed  on  minicomputers,  it  is  also  apparent  that  persistent  problems 
of  data  quality  are  not  necessarily  going  to  be  solved  by  downsizing  to  a 
lower  level.  Therefore,  concurrent  with  the  downsizing  of  minicomput- 
ers to  PC/LANs,  upsizing  to  centralized  systems  for  data  capture  is 
being  initiated. 

•  The  fundamental  information  flow  on  the  railroad  is  being  re-engineered 
employing  image  processing  systems  that  will  capture  and  process  the 
actual  bill  of  lading,  thus  permitting  the  preparation  of  both  operating 
and  accounting  documents  (such  as  waybills  and  accounts  receivable). 
One  Tandem  image  processing  system  servicing  70  remote  locations  has 
already  been  installed,  and  it  is  anticipated  that  "three  or  four"  could 
eliminate  the  minicomputer  network  and  also  significandy  reduce 
mainframe  processing.  The  current  thinking  is  to  run  all  bills  of  lading 
through  the  image  processing  system  regardless  of  whether  they  are 
received  on  paper  or  electronic  media. 

This  review  has  covered  over  30  years  of  what  is  essentially  the  same 
information  system.  The  information  architecture  has  fluctuated  depend- 
ing upon  available  technology  and  the  impacts  of  those  technologies  on 
the  quality  of  data  and  management  information.  The  telescoping  of 
several  decades  makes  those  innovations  appear  to  be  erratic,  but  they 
clearly  display  new  technologies  prompting  innovations  that  are,  in  turn, 
impacted  by  the  human  side  of  the  systems  equation. 

Despite  all  of  these  changes,  a  top-level  flow  chart  of  the  overall  railroad 
information  system  would  reveal  that  the  same  general  structure  has  been 
in  existence  since  "data  processing"  consisted  of  hand  preparation  of  paper 
documents  and  telegraphy  was  the  latest  innovation  in  communications.  It 
is  important  to  put  current  information  technology  into  historical  perspec- 
tive. 
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The  current  direction  toward  image  processing  represents: 

•  An  upsizing  of  currently  installed  minicomputers  to  fewer,  more  power- 
ful processors 

•  The  downsizing  of  some  former  minicomputer  functions  to  PC  LANs 

•  The  downsizing  of  some  mainframe  applications  to  the  image  processing 
systems 

•  The  recentralization  of  some  data  base  management  responsibilities  ■ 
formerly  distributed  to  minicomputers 

•  The  decentralization  of  some  data  base  management  functions  formerly 
centralized  on  mainframes 

It  is  obvious  that  the  information  architecture  can  shift  in  both  directions  at 
the  same  time,  and  the  railroad  does  not  currently  foresee  the  time  when 
mainframes  will  disappear.  They  will  remain  as  data  base  servers  well 
into  the  next  century.  What  is  happening  right  now  on  the  railroad  can 
quite  properly  be  classified  as  just  another  phase  in  a  continuing  effort  to 
"rightsize."  However,  there  is  no  question  that  at  this  point  in  time  there  is 
considerable  impetus  to  change  the  mainframe  environment. 

A  new  environment  prevails  in  the  information  age,  and  it  is  related  to  the 
people  side  of  the  total  information  system. 

g.  The  Human  Side  of  Downsizing  and  Empowerment 

Though  we  have  already  touched  on  the  human  side  of  the  data  quality 
problem,  it  is  more  complex  than  has  been  portrayed.  In  addition  to  the 
problems  associated  with  the  skills  and  motivation  of  operating  personnel 
to  maintain  data  quality  of  data  bases  not  directly  related  to  their  day-to- 
day work,  there  are  other  factors: 

•  Some  operating  personnel  try  to  beat  the  system  in  order  to  enhance 
their  own  performance  (or  at  least  avoid  detection  of  poor  performance). 

•  Other  operating  personnel  use  the  system  to  avoid  responsibility. 

•  Whenever  data  are  distributed,  internal  power  struggles  develop  over  the 
use  of  the  data.  The  struggle  between  operating  management  and  "bean 
counters"  is  traditional  on  the  railroad. 

•  Empowering  end  users  with  computer  power  and  data  can  lead  to  even 
more  pressing  problems.  It  was  stated  that  some  freight  agents  "...try  to 
steal  us  blind.  If  they  can  save  a  buck  they  will  tell  us  they  are  shipping 
tricycles  when  they  are  shipping  bicycles." 
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It  should  be  clear  that  data  quality  and  use  circumscribes  the  railroad's  use 
of  information  technology. 

4.  Function  and  Application  Selection  for  Downsizing 

The  "ancient  history"  that  has  been  reviewed  clearly  illustrates  the  fact 
that  downsizing  (or  empowerment)  has  been  directed  toward  two  primary 
elements  of  the  total  information  system — data  capture  (input)  and  data 
display  (output).  The  railroad's  experience  demonstrates  that  commonly 
accepted  wisdom  about  capturing  data  as  close  to  the  source  as  possible, 
and  providing  ready  access  to  data  may  have  adverse  as  well  as  beneficial 
consequences  over  the  long  term  (or  in  specific  instances). 

a.  Data,  Data  Everywhere  and  Still  No  Solution 

The  impetus  to  downsize  comes  from  mainframe  expense,  which  contin- 
ues to  grow  despite  two  decades  of  pushing  processing  power  outward  in 
the  network.  Applications  are  selected  for  downsizing  based  on  their 
ability  to  offload  the  mainframe.  For  example,  the  need  for  a  car  distribu- 
tion appUcadon,  which  was  the  primary  justification  for  the  operating 
department  ordering  its  own  computer  30  years  ago,  now  runs  on  a  Sun 
workstation  because  it  is  a  compute-intensive  application.  This  downsized 
applicadon  provides  an  important  example  of  the  limitations  of  informa- 
tion technology. 

*  While  the  car  distribution  "application"  has  been  moved  to  a  worksta- 
tion, much  of  the  mainframe  growth  on  the  railroad  over  the  last  30 
years  has  been  required  to  provide  the  data  base  necessary  to  support 
that  application.  (The  car  distribution  application  has  to  "know"  where 
all  cars  are  in  order  to  distribute  them,  and  only  the  mainframe 
"knows.") 

*  A  few  years  ago  Business  Week,  in  an  article  on  artificial  intelligence 
(expert  systems),  stated  that  the  railroad  was  using  AI  to  distribute 
equipment.  INPUT  called  the  VP  of  IS  and  asked  him  about  this  appli- 
cation. He  stated  that  he  wasn't  sure  exactly  what  people  meant  when 
they  talked  about  AI,  but  he  knew  that  this  particular  application  was 
strictiy  linear  programming.  He  stated  that  it  was  valuable  primarily  for 
training  purposes  when  moving  personnel  from  one  work  location  to 
another. 

*  When  INPUT  found  that  the  car  distribution  application  had  been  down- 
sized to  a  workstation  during  the  research  for  this  case  study,  it  inquired 
of  the  VP  again,  and  he  stated:  "It  is  not  one  of  our  better  applications." 
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•  What  started  out  as  a  relatively  "simple"  application  30  years  ago  con- 
tinues to  defy  the  best  efforts  of  experts  in  both  operations  research  and 
AL  Why?  Because  car  distribution  is  a  data  base  problem  and  not  a 
processing  problem. 

•  It  turns  out  that  it  isn't  simply  a  matter  of  knowing  which  cars  are  empty 
and  minimizing  mileage  to  either  get  them  to  their  next  load  or,  in  the 
case  of  foreign  cars,  off-line  where  you  don't  have  to  pay  for  their  use. 
Several  problems  arise  with  this  rolling  inventory  of  equipment  that 
make  data  base  management  rather  difficult: 

-  The  condition  of  cars  can  change  based  on  the  last  load. 

-  The  condition  of  cars  changes  because  of  minor  accidents  in  loading 
or  unloading. 

-  The  computer  can't  anticipate  random  changes  in  customer  car  orders 
or  "understand"  the  individual  customer's  standards  for  equipment 
acceptance  or  rejection. 

-  In  other  words,  the  human  element  comes  into  play  at  some  level  in 
servicing  individual  customers,  and  new  information  systems  require 
increasingly  detailed  data  to  be  reported. 

-  This,  in  turn,  means  that  even  essential  operating  data  may  suffer  in 
terms  of  quality. 

-  Improved  hardware  price/performance  does  not  solve  problems  of 
increasing  data  base  (or  knowledge  base)  size  and  complexity. 

•  The  car  distribution  problem  is  a  good  example  of  the  big  bang  theory  of 
systems  development — a  theory  that  assumes  that  if  we  just  have  enough 
data  we  can  solve  all  planning,  forecasting  and  control  problems.  Thirty 
years  of  history  and  considerable  expense  demonstrate  that  this  is  not 
necessarily  the  case. 

b.  Experience  Has  No  Substitute 

The  railroads  experience  clearly  demonstrates  the  following: 

•  Any  mainframe  application  can  theoretically  be  run  more  cost  effec- 
tively on  a  downsized  platform — provided  it  has  ready  access  to  data. 

•  Current  mainframes  are  necessary  only  to  run  complex  operating  sys- 
tems and  to  manage  large  data  bases. 
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•  The  expense  of  the  systems  software  to  drive  large  mainframes— in 
terms  of  both  processing  power  required  and  customer  out-of-pocket 
expenses — is  highly  visible  and  appears  indefensible  when  compared 
with  that  on  downsized  platforms. 

•  Therefore,  application  (or  function)  selection  should  be  relatively 
simple— merely  offload  everything  and  eliminate  the  mainframe;  or,  at 
the  very  least,  reduce  it  as  rapidly  as  possible  to  a  central  data  base 
machine. 

•  However,  in  actual  practice,  it  has  been  found  that  downsizing  (for  any 
number  of  reasons)  hits  limits  in  terms  of  data  quality  and  tends  to 
bounce  back  up  again. 

•  Therefore,  experience  shows  that  applications  and  functions  should  be 
downsized  from  mainframes  based  on  the  impact  on  data  quality;  or, 
more  specifically,  the  ability  to  manage  distributed  data  bases  on  a  wide- 
area  network. 

The  VP  of  IS  says  that  he  firmly  believes  that  there  is  a  proper  hierarchy 
of  data  storage,  and  that  it  can  be  managed.  However,  he  has  no  illusions 
that  this  will  be  easy.  The  evolving  information  architecture  will  require 
re-engineering  of  those  old  COBOL  programs,  and  the  effective  manage- 
ment of  distributed  data  bases  will  require  new,  complex  tools  (such  as 
object-oriented  programming  and  repositories). 

5.  Downsizing  Results 

The  railroad  has  been  remarkably  adept  in  the  effective  application  of 
technology.  It  was  among  the  first  to  eliminate  firemen  from  diesel 
locomotives.  Early  computer  applications  were  specifically  designed  to 
eliminate  unnecessary  clerical  expenses.  Despite  hitting  the  data  quality 
"wall"  on  several  occasions,  the  railroad  has  continued  to  pursue  the 
effective  use  of  the  latest  information  technology,  and  it  has  remained 
profitable  during  times  when  other  railroads  have  faced  bankruptcy. 

Since  the  subject  railroad  merged  with  another  in  1982,  the  combined 
headcount  of  the  two  railroads  has  gone  from  approximately  42,000  to 
27,000.  Car  loadings  during  that  time  have  not  declined  significantly,  and 
most  of  this  personnel  downsizing  can  be  directly  attributable  to  the 
effective  application  of  information  technology.  Since  this  period  coin- 
cides with  the  personal  computer  revolution,  it  can  be  safely  assumed  that 
microprocessor  technology  was  a  factor  in  the  improved  productivity  of 
the  remaining  workers. 
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However,  the  VP  of  IS  states  that  perhaps  downsizing  has  gone  too  rap- 
idly: "Service  to  customers  has  declined,  and  they  are  letting  us  know 
about  it"  Keeping  technological  and  organizational  downsizing  properly 
synchronized  will  remain  a  critical  consideration  in  the  1990s.  The  critical 
cells  in  the  university's  "cost  model"  provide  a  convenient  framework  for 
analyzing  the  major  issues  associated  with  the  railroad's  downsizing 
efforts. 

6.  The  Downsizing  Cost  Model 

The  railroad  has  been  running  essentially  the  same  applications  for  the  last 
30  years.  From  the  early  days  of  computers,  information  technology  has 
been  directly  involved  in  the  process  of  railroading.  During  that  time,  the 
price/performance  of  mainframe  computers  has  improved  by  over  two 
orders  of  magnitude  [23]  and  every  effort  has  been  made  to  take  advantage 
of  distributed  processing,  advanced  networking,  and  new  hardware  archi- 
tectures (minicomputers,  PCs  and  RISC-based  workstations),  but  the 
railroad  fmds  itself  with  constantly  escalating  expenses  for  mainframe 
hardware/software. 

When  the  cost  model  developed  by  the  university  is  applied  with  aware- 
ness of  the  railroad's  history,  current  situation,  and  expectations  from 
downsizing,  it  is  possible  to  obtain  some  valuable  insights  about 
management's  role  in  the  appHcation  of  information  technology,  and  how 
the  focus  has  changed  over  the  years. 

Exhibit  IV-3  identifies  the  most  significant  cells  in  the  downsizing  cost 
factor  matrix;  the  following  examines  them  by  column. 

a.  The  Data  Center 

(1)  Corporate  mainframes  are  a  highly  visible  expense,  and  it  is 
becoming  increasingly  difficult  to  rationalize  the  fact  that  funda- 
mental accounting  applications  that  used  to  run  on  an  IBM  705 
thirty  years  ago  now  run  on  an  IBM  3090,  Model  600,  while 
school  children  routinely  play  with  computers  that  have  over  one 
thousand  times  the  raw  processing  power  of  the  705.  The 
railroad's  objective  in  downsizing  is  to  offload  as  much  process- 
ing as  possible  to  the  more  cost-effective  platforms,  and  reduce 
the  mainframes  to  data  base  servers  and  network  controllers.  It  is 
assumed  that  this  will  contain  the  traditional  mainframe  growth 
pattern  and  eventually  reduce  the  actual  investment  in  mainframe 
technology. 


UIDCS 


e  1992  by  INPUT.  Reproduction  Prohibited. 


iy-29 


CASE  STUDIES  IN  DOWNSIZING 


INPUT 


EXHIBIT  IV-3 


Case  Study  #2 
Downsizing  Cost  Factors 
Client/Server  versus  Mainframe 
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Key:  1)  Plus  =  Increase  in  Expenditures 

2)  Minus  =  Decrease 
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4)  Null  =  Unable  to  Determine  from  Responses  Given 
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(2)  As  we  have  seen,  problems  of  data  quality  have  arisen  as  the 
railroad  has  distributed  processing  power  and  data  management 
responsibility  to  the  operating  department(s).  This  has  resulted  in 
cycles  of  centralization  and  decentralization  of  data  quality  respon- 
sibility. The  problem  is  that  data  management  becomes  increas- 
ingly complex  in  the  downsized  environment,  and  it  is  anticipated 
that  the  cost  of  maintaining  data  quality  will  increase  at  the  data 
center  regardless  of  the  advanced  technologies  (such  as  image 
processing)  employed. 

(3)  The  cost  of  systems  software  has  already  been  identified  as  a 
major  problem  by  the  data  center.  However,  the  insidious  (and 
even  sinister)  nature  of  the  problem  is  not  always  identified.  Most 
mainframe  upgrades  are  required  by  systems  software  and  not  by 
the  demands  of  customer  applications.  Basically,  the  customer 
pays  twice — once  in  terms  of  the  processing  power  required  to  run 
the  systems  software  and  then  for  the  software  itself  when  the 
mainframe  must  be  upgraded.  To  the  degree  that  downsizing  stops 
or  reverses  mainframe  growth,  systems  software  expense  will 
decrease  accordingly.  However,  the  mainframe  systems  software 
trap  remains  sprung  until  the  mainframes  are  actually  replaced,  and 
IS  management  has  a  hard  time  visualizing  how  this  can  be  accom- 
plished. 

(4)  The  impact  of  downsizing  on  data  center  staffing  is  not  known, 
but  data  quality  and  systems  software  support  are  becoming  in- 
creasingly complex.  Even  if  UNIX  and  OS/2  2.0  remain  "simpler" 
than  MVS/ESA,  the  data  center  will  have  responsibility  for  a 
substantially  more  complex  information  technology  infrastructure 
in  the  foreseeable  future.  Data  center  staff  will  either  have  to  be 
increased  to  support  this  new  environment  or  consultants  and/or 
systems  integrators  will  have  to  be  hired  to  support  end  users. 
(The  railroad  is  talking  about  doing  its  own  systems  software 
maintenance,  but  it  is  probable  that  management  will  be  looking 
for  reduced  data  center  expenses  as  downsizing  proceeds.  IS 
management  is  not  in  an  enviable  position.) 

(5)  Transition  costs  for  the  data  center  will  be  high,  with  more 
and  "different"  hardware/software  to  install,  operate  and  support. 
No  exact  figures  (or  plan)  is  currendy  available,  but  extracting 
itself  from  the  current  mainframe  hardware/software  trap  will  be 
a  "long,  painful  process." 

b.  Network  Services 

(1)  Despite  historic  investment  in  a  communications  technology, 
downsizing  and  image  processing  will  require  addidonal  invest- 
ment in  the  backbone  network. 
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(2)  Network  management  and  data  base  management  are  becom- 
ing practically  synonymous  in  a  distributed  data  base  environ- 
ment, and  the  railroad's  concern  about  data  quality  will  require 
network  services  to  provide  additional  support  in  terms  of  general 
connectivity,  and  data  base  synchronization  and  security. 

(3)  Network  complexity  continues  to  grow,  and  even  organiza- 
tions that  have  been  traditionally  communications  oriented  will 
have  to  either  increase  network  services  staff  or  seek  outside 
help. 

(4)  Changing  the  topography  of  the  communications  infrastructure 
is  always  expensive,  and  that  is  precisely  what  is  happening  during 
the  transition  period. 

c.  Application  Custodian 

(1)  While  the  immediate  focus  at  the  railroad  is  on  the  amount 
being  spent  outside  the  company  for  systems  software,  the  cost  of 
applications  development  has  been  a  longstanding  concern.  The  VP 
of  IS,  remembering  his  early  days  as  a  programmer,  stated  that  it  is 
"difficult  to  understand  why  things  take  so  long."  While  the  invest- 
ment in  COBOL  programs  is  one  of  the  factors  inhibiting  downsiz- 
ing, one  of  the  primary  objectives  of  downsizing  is  to  get  to  plat- 
forms that  provide  tools  that  are  easier  to  use — thereby  decreasing 
the  cost  of  applications  development. 

(2)  The  cost  of  maintaining  those  "impossible  to  maintain" 
COBOL  programs  is  a  major  part  of  the  mainframe  trap  because 
maintenance  of  existing  applications  must  take  priority  over  new 
development  work  and  re-engineering.  One  of  the  anticipated 
benefits  of  downsizing  (and  re-engineering)  is  that  the  new  appli- 
cations systems  will  be  easier  and  less  costly  to  maintain.  One 
way  of  achieving  this  saving  will  be  to  transfer  routine  mainte- 
nance to  end  users  at  workstations  (presumably  even  if  the  work- 
stations aren't  hardwired  to  print  out  that  the  IS  department  is  no 
longer  responsible  for  the  content  of  the  report). 

(3)  When  applications  are  split  between  clients  and  servers, 
problems  of  maintaining  data  quality  become  more  complicated. 
The  applications  custodian  will  have  to  expend  considerably  more 
resources  assuring  that  data  quality  is  maintained  and  improved. 

(4)  The  way  application  development  and  maintenance  expense  can  be 
reduced  is  by  decreasing  the  size  of  the  programming  (and  analysis) 
staff.  That  is  a  primary  objective  of  downsizing,  and  it  must  be  the 
primary  source  of  cost  justification. 
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(5)  However,  in  the  interim,  existing  applications  must  be 
maintained  while  client/server  applications  are  being  developed 
and/or  re-engineered.  As  it  was  for  the  university,  the  downsiz- 
ing transition  period  will  be  long  and  expensive. 

d.  End  User 

(1)  Downsizing  applications  from  minicomputers  to  client/ 
server  LANs,  and  (at  least)  some  mainframe  applications 
(including  transaction  processing)  to  an  image  processing 
system(s)  is  going  to  result  in  increased  cost  for  LANs  at  the 
end-user  level.  Image  processing  (even  with  compression) 
takes  more  bandwidth. 

(2)  New  downsized  applications  (including  image  processing) 
will  also  require  upgrading  or  replacing  currently  installed 
workstations  in  order  to  run  vendor  systems  software,  and  to 
drive  high-resolution  displays  and  their  GUIs. 

(3)  The  end-user  level  is  where  data  and  information  quality  are 
important,  and  the  railroad  is  already  experiencing  quality  prob- 
lems. Quality  will  be  every  one's  concern  as  technological  down- 
sizing proceeds,  and  more  effort  will  be  expended  at  all  levels  in 
the  information  systems  infrastructure. 

(4)  Starting  30  years  ago,  the  subject  railroad  used  information 
technology  to  downsize  staff.  Motivated  by  what  it  perceived  as 
being  featherbedding  (such  as  firemen  on  diesel  locomotives), 
management  took  the  position  that  even  trivial  clerical  work 
should  be  put  on  the  computer.  For  example,  watch  inspection 
cards  for  operating  personnel  were  prepared  by  computer  because 
that  was  the  last  remaining  function  for  some  clerks.  (It  may  not 
have  been  an  exciting  application,  but  it  permitted  management  to 
say  "there  is  no  work  for  this  employee"  when  negotiating  with  the 
clerks'  union.)  In  the  last  ten  years  the  railroad  has  again  made 
significant  staff  reductions,  while  operating  personnel  have  as- 
sumed increased  responsibilities  for  information  processing  activi- 
ties (including  data  quality).  Truncating  paper  documents  (such  as 
bills  of  lading)  will  relieve  operating  personnel  of  some  paper 
handling  chores,  but  it  appears  that  the  railroad  may  have  started  to 
cut  into  muscle  rather  than  fat  quite  some  time  ago.  Therefore,  it  is 
questionable  whether  end-user  staffing  levels  can  be  reduced 
without  serious  impact  on  customer  service. 

(5)  As  new  hardware/software  systems  are  installed,  users  will  incur 
increasing  training  and  overtime  costs  to  become  proficient  in  the  new 
systems.  In  addition,  maintaining  quality  of  both  the  new  and  the  old 
systems  will  be  especially  burdensome  if  the  transition  period  in  any 
particular  area  is  prolonged. 
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In  summary,  the  railroad  is  currently  concerned  primarily  with  improving 
the  quality  of  customer  service.  It  is  caught  in  an  expensive  mainframe 
trap  even  though  it  "downsized"  to  minicomputers  nearly  20  years  ago. 
To  extricate  itself  from  this  trap  while  improving  data  quality  and  cus- 
tomer service  will  require  immediate  and  dramatic  improvement  in  the 
performance  of  the  IS  department  itself  (data  center  and  application 
custodian)  because  it  appears  that  any  required  cost  justification  must 
come  from  a  reduction  in  mainframe  and  applications  development  costs. 

c  

Case  Study  #  3 — ^Proprietary  versus  Open  Systems 

Both  the  university  and  the  railroad  find  themselves  in  the  mainframe 
trap— no  matter  how  much  they  invest  in  new  technologies,  the  size  and 
expense  of  mainframes  seems  to  keep  going  up.  It  is  difficult  to  see  any 
end  in  sight,  but  both  are  formulating  downsizing  strategies  to  alleviate  the 
problems  associated  with  uncontrolled  mainframe  growth. 

Personnel  at  the  university  feel  that  a  primary  problem  is  that  the  univer- 
sity is  doing  too  much  of  its  own  mainframe  software  development  (both 
systems  and  applications).  They  anticipate  that  one  of  the  primary  ben- 
efits of  downsizing  will  be  to  enable  the  university  to  purchase  off-the- 
shelf  software. 

The  railroad,  on  the  other  hand,  is  saying  that  the  expense  of  mainframe 
systems  software  is  a  concem  of  management  all  the  way  up  to  the  board 
of  directors.  The  VP  of  IS  is  thinking  about  getting  image  processing 
source  code  and  maintaining  some  of  the  packages  internally,  wishing  for 
a  viable  alternate  to  mainframe  operating  systems,  and  even  thinking 
wistfully  of  the  "good  old  days"  when  he  was  part  of  a  group  that  did  all 
of  its  own  systems  software  development. 

The  next  case  study  is  of  a  major  international  energy  company  that 
essentially  avoided  the  mainframe  trap,  but  is  now  doing  an  assessment  of 
open  versus  proprietary  systems  in  the  downsized  environment. 

1.  Background 

The  subject  company  is  involved  in  oil  exploration  around  the  world,  and 
in  the  late  1970s  it  established  a  corporate  policy  of  avoiding  the  use  of 
mainframe  computers.  This  effectively  meant  that  it  created  a  downsized 
environment  by  avoiding  the  "upsizing"  inherent  in  a  mainframe-oriented 
infrastructure.  Avoiding  mainframes  also  meant  avoiding  SNA,  and  the 
company  installed  one  of  the  world's  largest  networks  of  DEC  VAX  and 
IBM  System/3X  (now  AS/400)  computer  systems.  It  remains  on  the 
leading  edge  of  network  computing. 
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Having  started  early  with  System/3 8s,  the  company  is  probably  the  most 
experienced  with  using  and  networking  AS/400  architecture  computers. 
That  experience  can  be  briefly  summarized  as  follows: 

•  The  System/3 8- AS/400  architecture  provides  substantially  easier  appli- 
cations development  and  data  base  management  than  does  the  main- 
frame environment. 

•  Early  use  of  the  relational  model  (integrated  into  the  hardware  architec- 
ture before  RDBMSs  were  commercially  available  from  software  ven- 
dors) has  provided  flexibility  and  an  applications  set  that  is  easy  to 
maintain. 

•  Network  management  facilities  have  consistently  been  far  ahead  of  the 
mainframe  environment,  and  the  company  is  convinced  that  the  AS/400 
is  the  finest  distributed  data  base  server  on  the  market  today.  Advanced 
Peer-to-Peer  Networking  (APPN)  was  available  on  System/3X  comput- 
ers prior  to  the  announcement  of  the  AS/400,  but  it  is  just  beginning  to 
appear  in  the  SAA  world. 

•  The  company  is  pleased  with  the  AS/400  hardware/software  architec- 
ture. It  has  invested  $15  million  in  development  of  network  applications 
based  on  this  technology,  and  "it  works." 

•  However,  there  has  been  a  long  and  continuing  struggle  with  IBM's 
SNA-oriented  Communications  Division,  which  for  years  has  stubbornly 
refused  to  acknowledge  that  networking  doesn't  require  an  IBM  main- 
frame. This  has  led  to  many  exasperated  exchanges  between  communi- 
cations experts  on  both  sides. 

-  There  was  a  running  dialogue  concerning  electronic  mail  which  was 
like  a  "soap  opera"  with  IBM  repeatedly  expressing  amazement  that  a 
worldwide  network  of  its  equipment  didn't  have  a  mainframe  to  route 
all  messages  through.  Now  when  IBM  has  finally  supported  elec- 
tronic mail  outside  of  SNA,  its  implementation  requires  both  parties  to 
"know"  each  other  in  order  for  one  to  direct  a  message  to  the  other. 
The  frustrated  AS/400  customer  cites  this  as  "another  example  of 
mainframe  mentality"  and  the  battle  continues. 

-  Then,  when  discussing  network  management  philosophy,  it  always 
seemed  to  get  back  to  the  old  SNA  problem  of  having  to  take  the 
entire  network  down  in  order  to  add  a  node. 

-  More  recently,  with  the  necessity  to  interface  with  UNIX-based 
networks  (the  company  is  also  heavily  into  RISC  workstations),  the 
question  of  support  for  TCP/IP  on  the  AS/400  has  led  to  a  continuing 
controversy  and  a  great  deal  of  contention. 
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-  And,  with  the  recent  move  of  some  IBM  communications  activities  to 
Europe,  it  seems  impossible  to  fmd  anyone  in  IBM  in  the  United 
States  who  knows  anything  about  Open  Systems  Interconnection 
(OSI). 

-  This  aU  leads  to  the  conclusion  that,  while  IBM  potentially  has  the 
best  distributed  data  base  server  in  the  AS/400,  it  is  not  being  sold  that 
way,  and  it  is  difficult  to  find  anyone  in  IBM  who  really  understands 
anything  except  the  traditional  SNA  approach  to  networking. 

-  This  type  of  frustration  has  finally  led  someone  in  network  services  at 
the  company  to  state  emphatically:  "IBM  should  just  get  out  of  the 
communications  business — period." 

With  that  as  background,  let's  take  a  look  at  a  specific  downsizing  prob- 
lem the  company  is  currendy  facing.  How  did  a  company  with  a  policy 
against  mainframes  get  a  downsizing  problem,  you  ask?  Very  simply; 
they  inherited  an  IBM  3081  from  a  business  partner  in  a  joint  venture. 

2.  The  Downsizing  Plan 

The  energy  company  is  now  the  less-than-proud  owner  of  an  IBM  3081 
servicing  five  remote  locations.  It  was  acquired  along  with  a  former 
business  partner  about  1984;  it  is  fully  depreciated  (except  for  a  leased 
3725  which  stands  out  like  a  red  SNA  flag  to  company  communications 
personnel);  the  software  cost  was  described  as  "eating  us  alive";  and  it  is 
in  clear  violation  of  the  company  policy  against  mainframes. 

The  IS  group  responsible  for  the  3081  was  recentiy  reorganized  and  now 
reports  to  corporate  headquarters.  A  simple  edict  came  down:  "Get  rid  of 
the  3081." 

A  conversion  group  was  set  up.  Since  the  company  has  approximately  60 
AS/400s  already  installed,  it  was  assumed  that  the  3081  would  be  down- 
sized to  that  platform. 

A  conversion  plan  was  drawn  up.  The  total  cost  was  approximately  $4 
million,  broken  down  as  follows:  $2.5  million  for  the  central  processing 
facility,  $.75  million  for  program  conversion,  and  $.75  million  for  the 
remote  data  network. 

The  problem  arose  when  corporate  administration  questioned  the  downsiz- 
ing plan. 

3.  The  Issue — Open  versus  Proprietary  Systems 

As  mentioned  previously,  the  energy  company  has  an  extensive  network 
of  both  AS/400S  and  DEC  VAXs.  At  one  time,  it  was  one  of  DEC  s 
largest  customers,  but  over  the  years  first  System/38s  and  now  AS/400s 
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have  been  gaining  percentage  of  IS  budget  dollars.  Like  other  minicom- 
puter vendors  faced  with  competition  from  the  AS/400,  DEC  has  belatedly 
seen  the  "wisdom"  of  open  systems. 

The  question  from  corporate  was:  Why  don't  we  downsize  to  DEC 
systems?  They  are  "open"  and  there  is  lots  of  packaged  software  avail- 
able. 

The  IS  department,  of  course,  feels  that  this  question  was  prompted  by  the 
engineering  side  of  the  house,  which  is  still  using  VAXs  that  have  been 
under  increasing  pressure  not  only  from  AS/400s  as  data  base  servers,  but 
from  RISC  workstations  for  engineering  work.  The  IS  department  now 
finds  itself  looking  at  the  relative  advantages  of  open  systems  (UNIX) 
versus  the  AS/400  for  downsizing  the  mainframe  applications. 

Given  the  extensive  network  of  AS/400s  already  installed,  the  possibility 
of  converting  completely  to  open  systems  may  be  idle  speculation.  How- 
ever, it  has  caused  the  IS  department  to  do  an  analysis  of  the  benefits 
perceived  from  the  AS/400  architecture  versus  mainframes,  and  to  assess 
its  long-range  direction  in  terms  of  open  versus  proprietary  systems. 

While  this  complicates  the  downsizing  cost  matrix,  it  can  still  serve  as  a 
convenient  framework  for  analysis. 

4.  The  Downsizing  Cost  Model 

For  this  case  study,  INPUT  split  the  columns  of  the  matrix  to  reflect  the 
perceived  benefits  that  have  been  achieved  by  avoiding  the  mainframe 
trap,  and  also  to  evaluate  the  relative  costs  of  the  AS/400  as  a  downsizing 
platform  versus  UNIX  (open  systems).  Exhibit  IV-4  shows  this  matrix. 

An  overview  of  the  matrix  reveals  that  there  is  general  consensus  in  the 
IS  department  that  the  AS/400  is  easier  to  use  (and  support)  than  either 
mainframes  or  UNIX-based  systems.  However,  it  should  be  pointed  out 
that  there  is  a  substantial  base  of  experience  to  support  this  conclusion  as 
far  as  mainframes  are  concerned,  but  the  IS  department  has  only  limited 
experience  and  knowledge  with  UNIX  systems  and  their  supporting 
software. 
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EXHIBIT  IV-4 


Case  Study  #3 
Downsizing  Cost  Factors 
AS/400  versus  Mainframe  and  UNIX 


Cost  Factors 

Data  Center 

Network 
Services 

Application 
Custodian 

End  User 

Application  Support 

Mfr.  UNIX 

Mfr.  UNIX 

Mfr.  UNIX 

Mfr.  UNIX 

Development 

Null 

Null 

Minus  (1)  ? 

Null 

Maintenance 

Null 

Null 

Minus  (2)  ? 

Null 

Documentation 

Null 

Null 

Null 

Null 

Training 

Null 

Null 

Neut.  (3)  Minus 

Null 

Hardware 

LANs 

Null 

Null 

Null 

Plus  (1)  Neut. 

Workstations 

Null 

Null 

Null 

Plus  (2)  Neut. 

Servers 

?  (1)Neut. 

Null 

Null 

Null 

Network  Backbone 

Null 

Minus  (1)  Neut. 

Null 

Null 

Environmentals 

Minus  (2)  Neut. 

Null 

Null 

Null 

Systems  Support 

Data  Quality 

Minus  (3)  Minus 

Plus  (2)  Minus 

Plus  (4)  Minus 

Plus  (3)  Neut. 

Standards 

Minus  (4)  Minus 

Plus  (3)  Minus 

Minus  (5)  Minus 

Null 

Systems  Software 

Minus  (5)  Minus 

Minus  (4)  Minus 

Null 

Null 

Staffing 

Staffing  Levels 

Minus  (6)  Minus 

?     (5)  ? 

Minus  (6)  Minus 

?  (4)  Minus 

Local  Expertise 

Minus  (7)  Minus 

Minus  (6)  Minus 

Null 

?  (4)  Minus 

Transition  Costs 

Plus    (8)  Minus 

Plus  (7)  Minus 

Plus  (7)  Minus 

Plus  (6)  Minus 

Key:  1)  Plus  =  Increase  in  Expenditures 

2)  Minus  =  Decrease 

3)  Neutral  =  Approximately  the  Same 

4)  Null  =  Unable  to  Determine  from  Responses  Given 
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Let's  briefly  examine  the  cells  that  have  been  rated. 

a.  Data  Center 

1)  Since  the  3081  is  fully  depreciated,  any  investment  in  new  hard- 
ware should  be  rated  a  plus;  but,  since  we  are  unsure  when  replace- 
ment or  upgrading  would  be  required,  we  have  left  the  question  open. 
We  assume  that  the  cost  of  AS/400  and  UNIX-based  downsized 
platforms  would  be  roughly  equivalent  (including  the  costs  of  systems 
software). 

2)  Environmental  costs  for  the  AS/400  would  be  less  than  for  the 
3081,  and  equivalent  to  those  for  other  downsized  platforms. 

3-5)  Systems  support  for  AS/400s  (in  terms  of  data  base  administra- 
tion, standards,  and  systems  programmers)  has  been  reported  to  be 
approximately  one-fifth  the  cost  of  that  for  IBM  mainframes.  [24] 
This  ratio  has  been  confirmed  by  the  subject  company  in  actual 
practice.  Though  the  ratio  would  probably  not  be  as  high  for  UNIX- 
based  systems,  the  integrated  architecture  of  the  AS/400  is  clearly 
easier  to  support  than  UNIX-based  systems  since  the  very  "openness" 
leads  to  numerous  versions  and  data  base  choices. 

6,7)  The  lower  systems  support  requirements  for  the  AS/400  result  in 
reduced  staffing  in  the  data  center,  and  the  ease  of  use  of  the  AS/400 
reduces  the  data  center  cost  of  providing  local  expertise  in  remote 
locations. 

8)  Conversion  is  always  costly,  but  it  is  felt  that  it  will  be  less  costly 
going  to  the  AS/400  than  to  other  downsizing  platforms.  (This  is 
especially  true  in  the  case  of  the  subject  company  because  of  current 
AS/400  expertise.) 

b.  Network  Services 

1)  The  leased  IBM  3725  is  visible  evidence  of  the  cost  of  SNA 
networks,  according  to  those  involved  with  network  services  at  the 
subject  company.  The  impact  on  the  backbone  network  is  rated  a 
standoff  between  AS/400  and  UNIX-based  systems  (but  communi- 
cations personnel  rate  the  AS/400  as  the  best  distributed  data  base 
server  available). 

2-4)  INPUT  is  not  sure  that  communications  personnel  interviewed 
would  agree  with  its  eventual  rating  of  these  particular  cells. 
However,  there  isn't  any  question  that  those  personnel  are  becom- 
ing increasingly  involved  in  what  previously  was  the  province  of 
data  base  administrators  and  systems  programming  personnel.  As 
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soon  as  data  bases  are  distributed  from  mainframes  out  to  the 
network  (and  especially  in  a  client/server  architecture),  the  distinc- 
tion between  data  base  management  and  network  management 
becomes  blurred.  [24]  One  person  interviewed  put  it  this  way: 

•  "It  is  fme  to  talk  about  scalability  and  merely  having  to  add  another 
$20,000  workstation  or  data  server  (the  low-end  models  of  the  AS/400 
are  down  to  this  level),  but  the  thought  that  you  can  do  away  with 
systems  programmers  doesn't  fly.  The  open  environment  increases 
complexity  dramatically.  Somebody  has  to  put  it  all  together  and  make 
it  work,  and  that  is  where  we  (data  communications  personnel)  are 
expected  to  provide  "connectivity"  and  we  just  aren't  staffed  to  do  it." 

Going  from  a  highly  centralized  mainframe  environment  increases 
problems  of  data  base  management  and  frequently  transfers  both  data 
base  administration  and  systems  programming  functions  from  the  data 
center  to  network  services.  This  is  especially  true  with  UNIX-based 
systems  that  are  "communications-oriented,"  but  have  only  relatively 
primitive  network  management  and  file  transfer  capabilities. 

Therefore,  when  moving  from  the  SNA  environment  on  the  IBM  3081, 
network  services  will  incur  additional  responsibility  for  data  quality  (in 
terms  of  synchronization,  responsiveness  and  security),  and  for  support- 
ing additional  "standards"  in  addition  to  (or  in  lieu  of)  SNA.  (OSI  is  but 
one  example.)  However,  when  viewed  from  the  point  of  view  of  net- 
work management  software,  the  AS/400  has  consistentiy  been  ahead  of 
mainframes;  and  OS/400  has  superior  transaction  processing  facilities 
compared  to  large-scale  UNIX-based  servers,  which  normally  don't 
have  transaction  monitors.  Hence  the  ratings. 

7)  Transition  costs  for  network  services  (which  are  essentially  the  cost  of 
integration  into  the  existing  network)  would  be  less  for  an  AS/400  than 
with  a  large  UNIX-based  server. 

c.  Application  Custodian 

1-2)  The  cost  of  application  development  and  maintenance  has 
been  clearly  demonstrated  to  be  less  on  the  AS/400  than  on  IBM 
mainframes.  It  was  stated  that  IS  personnel  who  came  from  the 
IBM  mainframe  environment  (as  many  of  them  did)  have  said  that 
they  will  never  go  back  to  that  development  environment.  How- 
ever, one  systems  person  interviewed  observed  that  some  people 
seemed  to  have  forgotten  just  how  bad  things  were  in  the  main- 
frame environment — they  had  become  spoiled  by  working  for  so 
many  years  with  the  System/38-AS/400  architecture. 


IV-40 


©  1992  by  INPUT.  Reproduction  Prohibited. 


UIDCS 


CASE  STUDIES  IN  DOWNSIZING 


INPUT 


This  brings  up  the  question  of  whether  UNIX  platforms  currently  have 
an  applications  development  environment,  or  packaged  software,  that  is 
comparable  (or  superior)  to  the  AS/400.  This  is  a  key  question  the 
company  is  currently  trying  to  answer,  and  it  is  a  key  issue  for  anyone 
planning  a  major  downsizing  project  from  a  mainframe.  INPUT  will 
analyze  this  issue  later,  after  making  the  following  observations: 

•  The  AS/400  currently  has  more  industrial-strength  business  applications 
available  than  any  UNIX-based  platform,  including  an  increasing  num- 
ber with  a  "money  back  guarantee." 

•  Some  reject  the  AS/400  as  a  "development  platform"  because  it  does  not 
have  highly  visible  CASE  tools,  and  has  only  recently  acquired  a  C 
cohipiler  (although  C  has  always  been  committed  as  an  SAA  language). 
It  should  be  understood  that  tens  of  thousands  of  small  companies,  and 
many  multibillion-dollar  enterprises  (such  as  the  subject  company),  have 
developed  all  of  their  necessary  business  applications  using  RPG  (with 
an  occasional  smattering  of  COBOL).  There  should  be  a  message  here. 

•  OS/400,  unlike  UNIX,  does  not  require  enhancement  with  DBMSs, 
transaction  monitors,  and  security  packages.  And  it  doesn't  require  a  lot 
of  additional  applications  development  tools  to  be  a  development  plat- 
form for  business  applications. 

3)  Less  training  should  be  required  for  applications  developers  and 
maintainers  because  of  the  integrated,  and  easy  to  use,  tool  set 
available  on  the  AS/400.  This  is  true  for  both  the  mainframe  envi- 
ronment and  alternative  UNIX-based  platforms  where  training  in  C 
for  either  RPG  or  COBOL  programmers  will  be  a  considerable 
expense.  (Remember  the  AS/400  is  being  evaluated  against  UNIX- 
based  systems,  and  the  minus  reflects  the  fact  that  training  expense 
would  be  less.  There  would  be  a  plus,  indicating  increased  cost,  in 
this  cell  for  UNIX  if  it  were  being  evaluated  as  the  downsizing 
platform.) 

4)  Once  we  get  away  from  those  old  mainframes  and  dumb 
terminals,  the  application  developer  and  maintainer  must  be  more 
concemed  with  data  quality.  How  will  data  be  distributed  between 
client  and  server?  How  will  these  files  and/or  data  bases  be  syn- 
chronized? How  will  privacy  and  security  be  maintained?.  These 
problems  are  substantially  easier  to  solve  on  the  AS/400  than  they 
are  on  UNIX-based  platforms. 

5)  Standards  concerns  for  the  applications  developer  are  less  on  the 
AS/400  because  there  aren't  as  many  alternatives  available.  There  is 
not  the  bewildering  array  of  operating  systems,  DBMSs  and  tools 
available  that  there  is  on  either  mainframes  or  UNIX-based  systems — 
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thus  simplifying  selection,  promulgation,  and  adherence  to  standards, 
and  avoiding  the  related  political  battles.  (Enforcing  standards  on 
programmers  is  one  of  the  most  thankless  and  time-consuming  jobs 
imaginable.) 

6)  Staffing  levels  for  the  applications  custodian  should  be  lower  for  the 
AS/400  than  for  either  the  mainframe  or  open  system  environment,  for 
all  of  the  reasons  mentioned  above. 

7)  The  transition  costs  for  converting  current  mainframe  applications  to 
AS/400  have  been  estimated  to  be  $750,000,  a  non-trivial  expense,  but 
estimated  to  be  lower  than  converting  to  a  UNIX-based  environment 

d.  End  User 

1-2)  The  cost  of  the  "remote  data  network"  to  support  downsizing 
the  308 1  to  an  AS/400  environment  has  also  been  estimated  at 
$750,000.  This  cost  would  include  LANs  and  workstations,  and  it 
is  assumed  that  the  cost  would  be  approximately  the  same  for 
UNIX-based  systems.  (As  an  aside,  IBM  has  pointed  out  to  its  AS/ 
400  customers  that  they  can  save  considerable  money  by  installing 
diskless  workstations,  but  the  subject  company  observed  that: 
"nobody  wants  diskless  workstations."  The  vendor's  host  mentality 
dies  slowly  as  the  world  goes  client/server.) 

3)  Given  workstations  with  disk  storage,  and  client/server  archi- 
tecture, the  user  must  accept  more  responsibility  for  data  quality 
and  security  than  in  an  SNA  environment.  This  results  in  additional 
expense  regardless  of  whether  it  can  be  quantified.  INPUT  esti- 
mates that  this  data  quality  expense  at  the  end-user  level  will  be 
approximately  the  same  in  either  the  AS/400  or  UNIX  environ- 
ments. 

4-5)  End-user  staffing  levels  and  the  need  for  local  expertise  will 
depend  upon  the  specific  applications  that  are  being  downsized,  and 
the  nature  of  the  conversion.  Straight  conversion  (as  opposed  to  re- 
engineering)  would  probably  have  little  impact  when  going  from  a 
mainframe  to  an  AS/400  environment,  but  one  would  hope  that  if 
applications  were  re-engineered,  end-user  staffing  levels  would  go 
down.  However,  generally  speaking,  the  AS/400  requires  less 
technical  knowledge  and  support  than  do  UNIX-based  systems,  and 
should  be  less  costly  in  terms  of  end-user  staffing  and  expertise. 

6)  Transition  costs  for  end  users  may  be  the  Achilles  heel  of  mainframe 
downsizing  efforts  because  of  problems  associated  with  running  parallel 
systems.  However,  the  transition  from  mainframe  to  AS/400  is  not  antici- 
pated to  be  nearly  as  traumatic  as  from  mainframe  to  UNIX-based  systems. 
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The  evaluation  of  an  AS/400  downsizing  effort  versus  on  "open  systems" 
approach  employing  DEC  equipment  and  UNIX  has  been  complicated 
considerably  by  a  recently  reported  strategic  shift  by  the  Open  Software 
Foundation  (OSF).  [25]  Essentially,  the  OSF  is: 

•  Shifting  emphasis  from  OSF/1  operating  system  development  to  concen- 
trate on  building  "distributed  computing  and  management  software" 

•  This  leaves  DEC  in  something  of  a  bind  because  it  had  stopped  making 
improvements  to  its  Ultrix  system  in  favor  of  moving  rapidly  from 
Ultrix  to  DEC/OSF/L  Now  it  must  reallocate  resources  back  to  Ultrix. 

(Oh,  the  joys  of  software  and  standards  development  by  C+-H-H  

consortium,  committee,  cooperative,  college  campus,  competitors  or 
consultants!) 

•  The  new  emphasis  of  OSF  is  directed  toward  the  strength  of  the  AS/400, 
and  it  is  more  than  a  decade  behind  other  developers. 

The  personal  impression  of  one  of  the  company  leaders  in  evaluating  the 
AS/400  and  open  systems  strategies  for  downsizing  is  that  any  decision  to 
move  aggressively  toward  open  systems  would  be  "disastrous"  for  the 
company.  But  the  jury  is  still  out  at  this  point. 


D   

Case  Study  #4 — Downsizing  and  the  Fight  for  Survival 

This  case  study  involves  a  major  minicomputer  company  that  has  itself 
been  adversely  impacted  by  PC  LANs  and  RISC  workstations.  Since  the 
early  1980s,  it  has  reduced  staffing  levels  by  nearly  60%  as  it  restructured 
to  meet  the  challenge  of  faster  product  cycles  and  lower  margins.  The 
only  way  to  retain  its  customer  base  and  stay  alive  was  to  adopt  RISC 
technology  and  UNIX  in  lieu  of  its  proprietary  systems. 

The  VP  of  IS  believes  that  the  company  could  not  have  survived  without 
drastic  changes  in  its  internal  information  systems  infrastructure.  He  also 
believes  that  both  technological  and  management  downsizing  will  be 
necessary  for  survival  by  all  industries  competing  in  global  markets.  He 
has  considerable  credibility  because  of  his  background. 

1.  Background 

The  background  of  the  company  is  similar  to  that  of  many  minicomputer 
companies.  It  has  been  technology  driven  rather  than  market  driven  for 
most  of  its  corporate  life.  Then,  as  it  was  beginning  to  adjust  to  the  chal- 
lenges of  the  commercial  market,  it  found  itself  confronted  with  the 
microprocessor  and  architectural  revolutions  of  the  1980s.  Now,  it  is 
struggling  to  survive  without  the  economy  of  scale  of  some  of  its  larger 
competitors. 
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The  background  of  the  VP  of  IS  is  not  similar  to  that  of  most  CIOs.  His 
company  was  chosen  as  a  case  study  because  he  has  first-hand  knowledge 
of  the  "upsizing"  case  study  that  was  presented  earlier  in  this  report.  He 
understands  the  "proper  hierarchical  model"  that  was  employed:  first, 
centralize  and  standardize;  then  provide  for  the  orderly  distribution  of 
processing  (and  data)  down  to  the  appropriate  level  in  the  hierarchy. 

He  remembers  this  model.  When  asked  about  the  current  theory  that 
infonnation  architectures  can  be  developed  from  the  bottom  up,  his  only 
statement  was:  "You  remember  Citibank  in  the  1970s  when  it  let  things 
get  out  of  control."  (This  was  a  reference  to  the  Citibank  experience  with 
distributed  processing  that  led  to  the  establishment  of  little  "data 
fiefdoms"  and  resulted  in  internal  warfare.) 

And,  he  is  no  stranger  to  the  client/server  model  that  was  employed  early 
in  the  1970s  in  retail  point-of-sale  and  wholesale  distribution  systems.  He 
held  positions  heading  up  a  computer  services  company  that  employed  one 
of  the  first  such  hierarchical  networks,  and  also  was  head  of  field  service 
for  an  organization  that  was  (at  that  time)  the  largest  supplier  of  point-of- 
sale  systems.  He  has  a  business  and  customer  service  orientation  com- 
bined with  pioneering  networking  experience.  This  is  a  difficult  combina- 
tion to  find  in  today's  topsy-turvy  IS  world. 

He  has  been  with  the  minicomputer  vendor  for  approximately  five  years, 
and  he  directed  his  attention  first  to  building  a  network  architecture. 

2.  The  Current  Network  Architecture 

The  current  network  architecture  is  described  as  "one  big  LAN."  It  has  a 
multiple  Tl  backbone,  and  digital  fiber  optic  LANs  interconnected  by 
routers.  There  are  three  field  data  centers,  and  6,000  devices  connected  to 
the  network.  The  concept  is  the  familiar  one  of  providing  ready  access  to 
"any  data  base  anywhere."  Now  the  network  has  been  built,  and  attention 
is  being  directed  toward  applications.  (It  was  considered  important  to 
establish  the  general  network  architecture  before  addressing  specific 
applications — undoubtedly  because  of  the  conviction  that  top-down  design 
is  necessary  if  the  integration  problems  inherent  in  bottom-up  develop- 
ment are  to  be  avoided.) 

Most  applications  are  home-grown  and  remain  on  proprietary  mainframe 
(Amdahl  5800s)  and  minicomputer  systems  (the  company's  own),  and 
some  of  them  are  about  15  years  old.  The  company  is  currentiy  looking  at 
all  applications  and  data  to  determine: 

•  Where  data  are  actually  needed  and  manipulated 

•  Where  data  should,  and  can  be,  moved  (distributed) 
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•  Which  are  the  most  cost-effective  platforms  for  data  residence  and 
processing 

•  Where  end-user  productivity  can  be  improved 

•  How  productivity  in  the  systems  development  process  can  be  improved 
through  the  use  of  packaged  software 

It  has  already  been  concluded  that  the  strategic  direction  will  be  toward 
downsizing  and  open  systems.  This  judgment  was  not  based  solely  on  the 
fact  that  the  company  had  already  reached  the  same  business  decision 
concerning  its  product  line,  but  rather  upon  the  expense  and  inflexibility  of 
current  information  systems.  As  mentioned  previously,  the  company  does 
not  believe  that  its  internal  IS  problems  are  any  different  from  those  of 
other  companies;  and,  therefore,  feels  confident  that  both  its  business  and 
information  systems  strategies  are  on  the  right  track. 

3.  Downsizing,  Open  Systems  and  Survival 

a.  Factors  Prompting  Downsizing  and  Open  Systems 

Current  applications  systems  are  not  responsive  to  either  changing  busi- 
ness needs  or  a  changing  technological  environment.  They  are  "frozen  in 
time"  on  expensive  hardware/software  platforms  and  absorb  a  high  per- 
centage of  IS  resources  just  to  maintain.  They  represent  "competitive 
disadvantage"  when  competitors  are  able  to  implement  (or  re-engineer) 
more  flexible  and  responsive  systems  on  more  cost-effective  platforms. 
Simple  survival  becomes  the  primary  factor  prompting  downsizing  when 
these  new  systems  result  in  improved  productivity  and  customer  service. 

b.  Factors  Inhibiting  Downsizing 

Many  existing  applications,  and  their  supporting  data  bases,  were  origi- 
nally designed  as  separate  systems.  There  is  a  need  for  apphcations 
integration  and  a  data  base  architecture  before  deciding  what  should,  and 
can,  be  moved  where.  Otherwise,  the  arbitrary  distribution  of  data  to 
surrounding  platforms  on  the  "one  big  LAN"  will  only  compound  an 
already  difficult  data  base  management  problem.  It  is  estimated  that  it 
will  be  two  or  three  years  before  substantial  progress  can  be  made  in 
distributing  mainframe  data  bases.  (We  assume  that  there  was  never  an 
effective  centraUzation  and  standardization  phase  while  the  company's 
network  of  mainframes  and  minis  was  evolving,  and  that  the  VP  of  IS  is 
now  developing  a  data  base  architecture  for  purposes  of  centralized  man- 
agement and  control.) 
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c  Application  Selection  for  Downsizing 

Although  mainframe  data  bases  pose  a  formidable  obstacle  to  rapid  imple- 
mentation of  the  downsizing  strategy,  the  VP  of  IS  states  that  there  are 
things  that  "can  be  done  today."  In  addition  to  the  usual  ad  hoc  reporting 
that  practically  everyone  agrees  can  be  downsized  to  more  cost-effective 
platforms,  he  emphasizes  the  fact  that  a  considerable  amount  of  current 
mainframe  transaction  processing  can  be  offloaded  (downsized)  as  well. 
The  company  is  currently  working  with  a  major  software  firm  on  the 
development  of  intelligent  data  streams  that  will  reallocate  work  between 
clients  and  servers  so  that  processing  is  done  on  the  most  cost-effective 
platform. 

As  mentioned  earlier,  a  top-down  review  of  applications  and  data  is  being 
made  to  design  an  information  architecture,  but  applications  are  selected 
for  downsizing  and  re-engineering  based  on  business  objectives.  For 
example: 

•  It  was  determined  that  customers  were  having  to  call  two  organizations 
in  order  to  straighten  out  billing  problems — one  for  regular  bills  and  one 
for  customer  service.  The  two  billing  systems  were  separate,  and  noth- 
ing alienates  customers  faster  than  billing  problems.  Since  a  major 
business  objective  was  to  retain  the  customer  base,  this  surfaced  as  a 
major  problem. 

•  The  whole  operation  was  put  under  one  management,  and  the  two 
systems  were  integrated  and  re-engineered  as  an  image  processing 
system  using  the  company's  new,  open  (UNIX-based)  product  line. 

•  The  new  applications  system  saved: 

-  $50,000  in  processing  costs 

-  $26,000  in  overtime  personnel  costs 

-  $3,000-4,000  in  paper  costs 

-  And,  most  important,  improved  service  to  the  customer 
4.  The  Downsizing  Cost  Model 

IS  management  has  assumed  an  important,  and  central,  role  in  the  survival 
strategy  of  the  subject  minicomputer  vendor.  Specifically,  the  VP  of  IS 
has  assumed  a  position  of  leadership  in  facilitating  management  strategies 
designed  to  make  the  company  more  competitive  in  the  most  beleaguered 
product  area  in  the  information  technology  industry.  It  is  obvious  that 
information  technology  must  play  an  increasingly  important  role  in  a 
company  that  is  making  such  drastic  personnel  reductions  while  attempt- 
ing to  maintain  its  customer  base. 
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Therefore,  unlike  other  companies,  the  role  of  the  CIO  (centralized  control 
of  information  resources)  is  actually  being  enhanced  in  this  company. 
Attesting  to  this  fact,  the  VP  of  IS  acquired  administrative  control  of 
European  information  systems  activities  during  the  course  of  the  research 
for  this  study. 

The  fact  that  the  information  systems  infrastructure  is  described  as  one  big 
LAN  is  significant  when  one  looks  at  the  anticipated  cost  impacts  of 
technological  downsizing.  It  seems  obvious  that  this  highly  centralized 
view  of  the  network  architecture  that  has  currently  been  implemented  is 
based  on  the  management  centralization  of  computing  resources  regardless 
of  where  they  are  located.  The  network  is  viewed  as  just  a  means  of 
"wiring  together"  all  of  the  computers  so  they  can  be  more  effectively 
managed. 

For  that  reason,  unlike  the  preceding  case  studies,  network  services  will  be 
integrated  with  the  data  center  in  the  cost  model  shown  in  Exhibit  IV-5. 

a.  Data  Center 

Downsizing  is  the  aftermath  of  the  personal  computer  revolution.  The 
data  center  is  expected  to  provide  quality  data  so  end  users  can  control 
their  own  destinies.  The  IS  department  has  been  relegated  to  the  role  of 
data  custodian.  So  the  story  goes. 

This  case  study  does  not  fit  the  story  line.  The  data  center  has  extended  its 
power  through  the  development  of  an  all-encompassing  network  architec- 
ture. Downsizing  is  viewed  as  the  "orderly  distribution  of  processing  and 
data"  to  appropriate  levels  in  the  processing  (and  organizational)  hierar- 
chy. Depending  upon  one's  point  of  view,  this  may  be  viewed  as  the 
triumph  of  professionahsm  over  the  rabble  or  the  ruthless  suppression  of 
the  legitimate  aspirations  of  end  users  for  empowerment. 

However,  there  is  no  question  about  who  is  in  control  here,  and  this  is 
reflected  in  the  general  cost  analysis. 

1-2)  Since  the  data  center  is  responsible  for  the  orderly  distribution  of 
processing  and  data  to  end  users,  it  will  have  increased  responsibility  (and 
cost)  for  documentation  and  training  as  downsizing  proceeds. 

3-5)  A  considerable  investment  has  been  made  in  the  "one  big 
LAN,"  and  increased  investment  will  be  necessary  as  downsizing 
proceeds.  It  is  anticipated  that  the  increased  cost  of  LANs  and 
network  backbone  will  be  more  than  offset  by  savings  in  "serv- 
ers" (mainframes)  as  downsizing  proceeds.  The  statement  was 
made  that  there  are  potentially  "tremendous  savings"  on  hard- 
ware since  RISC-based  minicomputers  will  cost  only  a  quarter  as 
much  as  current  mainframes. 
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EXHIBIT  V-5 


Case  Study  #4 
Downsizing  Cost  Factors 
Client/Server  versus  Current 


Cost  Factors 

Data  Center 
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Services 

Application 
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End  User 

Application  Support 

Development 

Null 
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Null 
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Maintenance 

Null 
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Null 
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Plus  (2) 

Documentation 

Plus  (1) 

Null 

Plus  (3) 

Null 

Training 
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Null 

Null 

Null 

Hardware 
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Plus  (3) 
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Null 
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Null 

bnvironmentals 

M.  .11 

Null 
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Null 
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Svstems  Suooort 

Data  Quality 

Plus  (6) 

Null 

Plus  (4) 

Plus  (4) 

Standards 

Plus  (7) 

Null 

Plus  (5) 

Null 

Systems  Software 

Minus  (8) 

Null 

Null 

Null 

Staffing 

Staffing  Levels 

Plus  (9) 

Null 

Minus  (6) 

Minus  (5) 

Local  Expertise 

Plus  (10) 

Null 

Null 

Null 

Transition  Costs 

Plus  (11) 

Null 

Plus  (7) 

Plus  (6) 

Key:  1)  Plus  =  Increase  in  Expenditures 

2)  Minus  =  Decrease 

3)  Neut.ral  =  Approximately  the  Same 

4)  Null  =  Unable  to  Determine  from  Responses  Given 
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6-7)  The  data  center  has  retained  responsibility  for  data  quality  during 
downsizing.  Distributed  data  base  management  (and  administration)  will 
require  more  effort  as  downsizing  proceeds.  In  order  to  minimize  com- 
plexity (and  avoid  chaos),  it  can  be  anticipated  that  additional  standards 
for  client  hardware  and  software  will  have  to  be  established  and  main- 
tained. (While  some  standards  problems  have  been  simplified  by  the 
company  adopting  an  open  systems  strategy  for  its  product  line,  there 
remain  many  open  issues  in  the  software  area — especially  in  the  applica- 
tions enabling  area.) 

8)  One  of  the  primary  incentives  to  downsize  and  get  rid  of  mainframes  is 
the  burden  of  systems  software  on  both  performance  and  the  IS  budget. 
(Downsizing  will  eventually  drive  down  the  cost  of  mainframe  systems 
software  even  if  mainframes  aren't  replaced — competition  can  work 
wonders.) 

9)  The  responsibility  for  managing  "one  big  LAN"  and  the  increasing 
importance  of  IS  in  supporting  organizational  downsizing  will  insure  that 
staffing  levels  for  the  information  systems  infrastructure  (the  data  center, 
including  network  services)  will  increase.  Some  of  this  increase  may  be 
hidden  by  normal  (and  creative)  accounting,  but  the  number  of  people 
literally  working  for  the  data  center  is  going  to  increase. 

10)  The  data  center  will  also  be  responsible  for  providing  local  expertise 
in  the  application  and  use  of  information  technology  resources.  This  will 
require  increased  staffing  even  if  end  users  pay,  either  directly  or  indi- 
rectly, for  these  services. 

11)  The  fact  that  it  will  take  two  or  three  years  to  make  significant 
progress  toward  eliminating  mainframes  indicates  that  there  will  be  sig- 
nificant transition  costs.  Hopefully,  the  awareness  that  downsizing  will 
require  considerable  effort  will  permit  transition  costs  to  be  minimized. 
Unreasonable  expectations,  especially  in  terms  of  immediately  reduced 
mainframe  costs,  can  be  extremely  expensive  when  they  are  not  met. 

b.  Application  Custodian 

1-2)  The  VP  of  IS  remembers  when  he  worked  closely  with  IBM  in 
developing  an  early  bill  of  materials  processor,  which  later  became  an 
IBM  product.  He  is  firmly  of  the  opinion  that  packaged  software  will  play 
an  increasingly  important  role  in  the  downsized,  open  environment. 
Reducing  the  cost  of  applications  development  and  maintenance  is  a 
primary  source  of  cost  justification  for  moving  to  that  environment.  This 
company  has  bet  its  future  that  these  cost  savings  will  materialize — not 
only  internally,  but  in  the  marketplace.  However,  being  the  pragmatist  he 
is,  die  VP  of  IS  readily  states  the  following: 

•  The  key  to  success  in  any  systems  project,  whether  building  a  network 
or  developing  a  complex  application  system,  is  "good  people" — prefer- 
ably a  few  good  people. 
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•  Another  important  factor  is  attacking  the  project  head  on  rather  than 
considering  all  of  the  alternative  implementation  strategies.  (In  other 
words,  actually  doing  it  rather  than  talking  about  it.) 

•  Last,  but  not  least,  he  recommends  "measuring  twice  and  cutting 
once"— in  other  words  take  care  to  know  exactly  what  you  want  to  do 
and  do  it  right  the  first  time;  it  is  usually  extremely  expensive  to  correct 
analysis  problems  later  in  the  systems  development  process. 

3)  The  increased  documentation  costs  will  occur  because  standalone 
systems  are  being  re-engineered  and  integrated  as  they  are  being  down- 
sized. As  data  base  management  becomes  more  complex,  more  documen- 
tation is  required  on  the  part  of  the  applications  custodian  to  assure  proper 
use  of  data  and  to  insure  against  data  base  contamination. 

4-5)  The  applications  custodian  becomes  the  vital  link  between  client  and 
server  in  terms  of  data  quality  and  the  standards  necessary  to  maintain 
quality.  It  is  the  cooperative  application  that  bridges  these  two  domains, 
and  it  is  a  codependent  relationship.  This  is  especially  true  because  the 
case  study  company  is  planning  to  move  some  transaction  processing  to 
minicomputers  and  workstations  before  mainframe  data  bases  can  be  fully 
distributed. 

6)  Despite  the  increase  in  data  base  management  responsibilities,  it  is 
anticipated  that  reduced  application  development  and  maintenance  costs 
will  permit  a  net  reduction  in  staffing. 

7)  An  important  point  was  made  about  transition  costs — why  should  the 
company  be  so  worried  about  transition  costs  when  many  of  them  are 
really  maintenance  costs?  The  fact  that  there  is  a  new  term  (downsizing), 
and  a  stated  goal  (offloading  of  mainframes)  should  not  obscure  the  fact 
that  a  great  many  applications  have  been  re-engineered  and/or  shifted  to 
more  cost-effective  platforms  under  the  guise  of  maintenance  for  years. 
Some  provision  should  be  made  for  writing  off  transition  costs  as  mainte- 
nance or  vice  versa  (whatever  makes  management  happy).  (The  next  case 
study  will  demonstrate  that  this  particular  IS  VP  is  not  the  only  one  to 
view  cost  in  this  manner.) 

c  End  User 

Drastic  downsizing  of  personnel  has  already  taken  place  in  the  company. 
Information  technology  is  being  substituted  for  these  human  activities. 
That  means  that  the  remaining  employees,  at  all  levels,  will  be  spending 
more  time  dealing  with  artificial  systems  at  the  human/machine  dyad. 

1-2)  By  INPUT'S  definition,  someone  using  a  spreadsheet  package  or  a 
report  writer  is  developing  and/or  maintaining  an  application.  [2]  The 
case  study  company  acknowledges  that  employees,  of  necessity,  must 
spend  more  time  sitting  at  their  workstations  and  using  these  (or  other) 
tools. 
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3)  The  client/server  environment  will  require  more  invesmient  in  work- 
stations to  run  advanced  operating  systems,  applications  enabling  tools, 
and  applications.  Access  to  data  anywhere  on  this  "one  big  LAN"  implies 
a  level  of  systems  software  sophistication  that  will  assure  upgrading  of 
practically  all  existing  personal  computers.  (Standards  set  will  be  for 
minimum  configurations,  but  some  provision  will  probably  have  to  be 
made  to  control  these  costs— whether  by  the  data  center  or  by  the  end- user 
departments.) 

4)  Personal  data  bases,  if  they  are  shared,  will  require  a  different  level  of 
quality  control  than  standalone  PC  users  have  normally  exercised — 
regardless  of  whether  these  standards  are  established  by  the  data  center  or 
applications  custodians. 

5)  Regardless  of  how  severe  the  cuts  have  been  to  date,  the  ultimate 
objective  of  downsizing  is  to  provide  better  information  technology  tools 
so  fewer  employees  can  do  more  (and  perhaps  superior)  work  in  less  time 
at  the  end-user  level. 

6)  Transition  costs  will  exist  at  the  end-user  level  even  as  staffing  levels 
decrease.  Until  information  technology  catches  up  with  staff  reductions, 
these  costs  can  manifest  themselves  in  overtime  charges.  (The  billing 
systems  cited  previously  are  a  good  example;  the  downsized  system 
reportedly  "saved"  2,600  hours  of  overtime.) 

This  has  been  a  case  in  which  downsizing  is  literally  a  question  of  sur- 
vival. The  fact  that  internal  information  systems  are  being  emphasized  as 
a  means  of  achieving  management  objectives  during  this  difficult  period 
indicates  that  management  has  the  courage  of  its  convictions  concerning 
both  its  business  plan  and  the  current  course  of  information  technology 
toward  downsizing  and  open  systems. 

All  of  the  preceding  case  studies  have  involved  large  organizations. 

Several  fundamental  conclusions  about  the  trend  to  downsizing  can  be 
reached  from  the  preceding  case  studies: 

•  Mainframe  hardware/software  is  viewed  as  being  complex,  difficult  to 
use,  and  expensive. 

•  IS  management's  traditional  reliance  on  mainframe  solutions  is  becom- 
ing increasingly  difficult  to  rationalize  against  the  potential  price/perfor- 
mance advantages  of  alternative  platforms. 

•  There  is  considerable  desire  and  motivation  on  the  part  of  management 
to  be  freed  from  what  is  viewed  as  being  an  oppressive,  and  even  ex- 
ploitative, information  systems  infrastructure  that  is  not  responsive  to 
business  needs. 
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•  Devising  an  effective  strategy  for  eliminating  the  mainframe  burden  (or 
escaping  from  the  mainframe  trap)  seems  to  be  extremely  complex, 
technically  and  politically. 

The  next  case  study  records  the  experience  of  one  of  the  few  companies 
that  has  actually  replaced  all  of  its  mainframe  computers  under  the  down- 
sizing "umbrella." 


E_  

Case  Study  #5- — Actual  Transition  to  a  Downsized  Environment 

This  case  study  of  a  medium-sized  consumer  products  company  owned  by 
a  major  international  conglomerate  has  been  publicized  in  vendor  and 
professional  publications,  and  in  the  trade  press,  as  an  example  of  the 
advantages  of  downsizing  from  an  IBM  mainframe  to  an  open  systems 
(UNIX)  environment  The  case  turns  out  to  be  substantially  more  com- 
plex than  would  appear  on  the  surface;  but,  while  INPUT'S  analysis  raises 
some  additional  questions,  it  does  clarify  some  of  the  major  issues  and 
cost  assumptions. 

Ic  Background 

The  subject  company  had  already  started  a  major  applications  review 
when  the  international  conglomerate  took  over  in  late  1987.  At  that  time, 
there  were  two  Unisys  (an  A 12  and  an  A09)  and  one  IBM  mainframe 
(3090,  120E)  installed.  Some  of  the  applications  on  the  Unisys  systems 
were  quite  old  and  the  thought  was  to  upgrade  the  3090  (at  a  cost  of 
approximately  $1  million)  and  convert  at  least  some  of  the  Unisys  applica- 
tions to  that  system. 

a.  Factors  Prompting  Downsizing 

The  new  VP  of  IS  had  installed  several  Pyramid  systems  elsewhere  in  the 
conglomerate  and  was  convinced  of  the  advantages  of  open  systems  and 
the  cost  benefits  that  could  be  derived  from  downsizing.  He  could  sense 
the  proprietary  mainframe  trap,  and  he  had  the  practical  experience  to 
know  there  was  a  workable  alternative.  A  command  decision  was  made  to 
eliminate  the  3090  as  soon  as  possible  and  avoid  the  hardware/software 
cost  escalation  inherent  in  starting  at  the  low  end  of  the  IBM  mainframe 
line.  The  Unisys  mainframe  applications  would  be  downsized  later. 

b.  Factors  Inhibiting  Downsizing 

The  company  had  a  traditional  COBOL-oriented  shop  unfamiliar  with 
either  the  tools  or  concepts  of  opens  systems  and  downsizing;  in  addition, 
it  was  located  in  a  small  town  where  the  supply  of  skilled  systems  person- 
nel was  extremely  limited. 
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In  addition,  the  company  was  losing  money  and  the  parent  conglomerate 
would  soon  be  forced  to  seek  bankruptcy  protection. 

Fortunately,  the  VP  of  IS's  combination  of  decisiveness  and  actual  experi- 
ence with  Pyramid  systems  resulted  in  successfully  forestalling  what  could 
have  been  a  traditional  spiral  of  increasing  information  technology  costs. 
This  is  not  to  say  that  transition  was  easy. 

2.  Transition  to  Downsizing 
a.  Important  Decisions 

As  INPUT  has  played  various  companies'  downsizing  plans  (or  thinking) 
against  the  cost  model,  the  importance  of  transition  costs  has  become 
apparent.  A  major  transition  cost  that  is  frequently  overlooked  is  deciding 
what  is  "feasible"  and  then  selecting  among  various  alternatives.  It  is 
possible  to  spend  an  enormous  amount  of  time  and  money  deciding  what 
to  do  without  achieving  any  benefits  whatsoever.  For  example,  the  uni- 
versity narrowly  avoided  spending  $500,000  for  "advice  and  counsel"  on 
an  information  architecture  that  would  have  resulted  in  limited  tangible 
benefits  in  actually  moving  toward  that  architecture.  It  is  possible  to  incur 
substantial  "transition  costs"  while  standing  still  or  retrogressing. 

The  subject  company  avoided  these  unnecessary,  up-front  transition  costs; 
and  by  prompt  action  stopped  an  in-process  "upsizing"  that  would  have 
made  any  later  downsizing  effort  all  the  more  difficult.  The  imponance  of 
this  decisive  action  cannot  be  overemphasized. 

Two  other  important  decisions  were  made  early  on: 

•  It  was  decided  that  large  systems  integrators  would  not  be  employed  to 
assist  with  the  downsizing  effort  because:  "We  were  in  a  hurry.  We 
couldn't  afford  to  sit  down  with  a  large  integrator  and  write  contracts 
dotting  every  'i'  and  crossing  every 't'."  (It  was  recently  reported  that, 
as  an  alternative,  a  small  systems  integrator  specializing  in  "mainframe 
knockoffs  for  UNIX  and  UNIX  clones"  was  employed  and  "turned 
around  the  job  (of  replacing  the  3090)  in  12  months  at  a  cost  of  approxi- 
mately $250,000."  [26]  This  turns  out  to  be  somewhat  misleading,  and 
it  will  be  discussed  later.) 

•  It  was  also  decided  that  3090  appHcations  would  not  be  re-engineered, 
but  rather  converted  as  rapidly  as  possible  to  the  Pyramid  system.  This 
enabled  the  3090  to  be  replaced  in  1989 — a  year  after  the  decision  was 
made.  If  applications  had  been  re-engineered,  the  conversion  "would 
still  be  going  on."  This  requires  some  explanation. 


UIDCS 


C  1992  by  INPUT.  Reproduction  Prohibited. 


IV-53 


CASE  STUDIES  IN  DOWNSIZING 


INPUT 


b.  Re-engineering  During  Downsizing 

The  IBM  mainframe  was  being  used  primarily  for  decision  support  for 
sales  and  marketing,  and  the  Unisys  systems  were  used  for  operational 
applications  (such  as  manufacturing).  The  thinking  had  originally  been 
that  the  operational  systems  would  be  moved  to  the  upgraded  IBM  3090 
and  more  closely  integrated  with  the  decision  support  systems.  The 
decision  not  to  re-engineer  when  downsizing  was  specifically  directed 
toward  shortening  the  transition  period  (for  downsizing  the  3090  applica- 
tions) and  achieving  major  cost  benefits  as  soon  as  possible.  This  resulted 
in  the  following: 

•  The  3090  applications  (stated  to  be  "approximately  2,000  procedures 
and  programs")  were  rapidly  converted  using  Oracle  on  the  Pyramid 
systems.  However,  this  rapid  conversion  was  possible  because  most 
transaction  processing  (updates)  remained  on  the  Unisys  systems. 

•  Some  of  the  Unisys  operational  systems  were  old  COBOL  programs  that 
were  unstructured  and  extremely  difficult  to  maintain.  There  was  never 
any  question  that  they  would  have  to  be  re-engineered.  These  applica- 
tions have  been  downsized  primarily  using  Oracle  and  Pyramid  systems 
and  Unisys  6000s  (under  SCO  UNIX). 

•  However,  it  has  been  found  that  the  re-engineering  of  these  applications 
systems  require  programming  in  C-i-,  and  the  last  of  the  Unisys  main- 
frames is  just  being  replaced — nearly  three  years  after  the  3090  was 
rolled  out  the  door.  (This  would  seem  to  substantiate  the  fact  that  the 
3090  downsizing  effort  "would  still  be  going  on"  if  it  had  been  decided 
to  re-engineer  and  integrate  those  applications  while  downsizing.) 

Some  good  business  and  technical  decisions  were  made  during  the 
course  of  this  downsizing  effort,  and  it  was  a  significant  achievement. 
The  results  when  viewed  against  the  cost  model  are  both  impressive  and 
informative. 

3.  The  Cost  Model 

One  thing  that  must  be  taken  into  consideration  in  viewing  the  impact  of 
downsizing  on  costs  is  the  fact  that  the  company's  business  took  a  nose- 
dive during  this  period.  Production  (and  presumably  revenue)  dropped 
approximately  30%,  and  the  parent  conglomerate  was  operating  under 
bankruptcy  protection.  It  is  difficult  to  assess  how  important  this  busi- 
ness downsizing  was  in  prompting  and  accounting  for  the  impact  of 
information  technology  downsizing,  but  the  generally  depressed  environ- 
ment should  be  borne  in  mind.  The  downsizing  cost  factor  matrix  for 
this  case  study  company  is  shown  in  Exhibit  IV-6. 
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EXHIBIT  IV-6 


Case  Study  #5 
Downsizing  Cost  Factors 
Client/Server  versus  Mainframe 


Cost  Factors 

Data  Center 

Network 
Services 

Application 
Custodian 

End  User 

Application  Support 

Development 

Null 

Null 

?(1) 

Null 

Maintenance 

Null 

Null 

?(2) 

Null 

Documentation 

Null 

Null 

Null 

Null 

Trainino 

Plus  (1) 

Null 

Null 

Hardware 

LANs 

Null 

Null 

Null 

Null 

Workstations 

Null 

Null 

Null 

Minus  (1) 

Servers 

Minus  (2) 

Null 

Null 

Null 

Network  Backbone 

Null 

Null 

Null 

Null 

Environmentais 

Minus  (3) 

Null 

Null 

Null 

Systems  Support 

Data  Quality 

Null 

Null 

?  (4) 

Plus  (2) 

Standards 

Null 

Null 

Null 

Null 

Systems  Software 

Minus  (4) 

Null 

Null 

Null 

Staffing 

Staffing  Levels 

Minus-Plus  (5) 

Null 

Minus-Plus  (5) 

Minus  (3) 

Local  Expertise 

Plus  (6) 

Null 

Plus  (6) 

Null 

Transition  Costs 

Plus  (7) 

Plus  (1) 

Plus  (7) 

Plus  (4) 

Key:  1)  Plus  =  Increase  in  Expenditures 

2)  Minus  =  Decrease 

3)  Neut.ral  =  Approximately  the  Same 

4)  Null  =  Unable  to  Determine  from  Responses  Given 
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a.  Data  Center 

1)  While  up-front  costs  associated  with  the  downsizing  effort  were  kept 
to  a  minimum  by  the  decisive  actions  taken  in  deciding  to  go  to  the  Pyra- 
mid-Oracle open  systems  environment,  the  initial  training  costs  associated 
with  downsizing  cannot  be  minimized.  It  was  reported  that  the  company 
invested  nearly  900  man-days  in  training  for  various  development  and 
technical  staff  in  order  to  get  the  downsizing  effort  under  way.  Since  the 
total  IS  staff  was  94  people  (and  shrinking)  this  represents  approximately 
10  days  of  training  per  employee — a  significant  initial  investment  under 
any  circumstances. 

2-4)  However,  such  training  costs  can  be  easily  justified  when  mainframes 
can  actually  be  replaced. 

•  It  was  estimated  that  over  $500,000  a  year  was  saved  on  software  license 
and  maintenance  fees  on  the  3090  alone. 

•  In  addition,  lower  operating  costs  in  the  form  of  depreciation  of  equip- 
ment, cooling,  power,  etc.  were  stated  to  be  "substantially  more  than 
one-half  million  dollars"  when  the  3090  was  replaced. 

•  For  the  last  half  of  1992,  the  base  operating  budget  will  be  running  at  an 
annual  rate  of  $1.2  million  per  year,  down  from  $3.9  million  before  the 
downsizing  effort  started! 

•  It  is  also  reported  that  the  Pyramid  system(s)  provide  improved  re- 
sponse time  and  have  more  capacity  than  the  replaced  mainframes.  In 
addition,  there  is  improved  scalability  for  containing  costs  of  new 
applications. 

Even  allowing  for  decreased  business  volumes,  bankruptcy  protection,  and 
creative  accounting,  one  has  to  be  impressed  with  these  results. 

5)  Overall  IS  staffing  levels  (including  systems  development)  had  been 
reduced  from  the  original  94  to  68  when  research  for  this  report  was 
completed.  This  is  a  reduction  of  approximately  30%  and  corresponds 
closely  with  the  previously  cited  30%  reduction  in  business  volumes. 
However,  salary  costs  over  the  same  period  have  actually  increased  from 
$2.7  million  (1988-89)  to  a  current  level  of  approximately  $3.0  million  per 
year.  For  the  data  center,  this  can  be  explained  as  followed: 

•  It  is  difficult  to  find  UNIX  systems  programmers  and/or  systems  admin- 
istrators, and  a  premium  price  must  be  paid  for  them. 

•  Once  personnel  have  been  trained  in  UNIX,  they  become  more  valuable; 
and  with  the  trend  toward  downsizing,  they  have  considerable  mobility. 
Therefore,  salaries  tend  to  increase  rapidly.  (Actually,  the  subject 
company  is  located  in  a  relatively  small  town,  and  this  problem 
shouldn't  be  as  bad  there  as  it  would  be  elsewhere.) 
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•  Therefore,  it  is  not  entirely  unreasonable  that  salaries  have  increased  by 
approximately  30%  over  the  last  four  years  as  headcount  has  decreased. 

6)  When  moving  to  a  UNIX  client/server  environment  from  what 
was  essentially  a  dumb  terminal  environment,  it  is  necessary  for  the 
data  center  to  provide  local  expertise  and  support  for  the  LANs.  Once 
again,  this  is  an  additional  expense  even  if  data  center  headcount 
decreases  overall  (or  how  this  expense  is  treated  for  accounting 
purposes). 

7)  Transition  costs  for  the  data  center  were  minimized  because  of 
the  rapid  replacement  of  the  3090,  but  there  was  a  period  when  IBM, 
Pyramid  and  Unisys  systems  were  all  installed.  Just  as  with  training 
costs,  some  up-front  investment  is  needed  during  major  equipment 
transitions.  Anticipation  of  these  costs  was  the  reason  the  VP  of  IS 
was  "in  a  hurry"  to  downsize. 

b.  Network  Services 

1)  Running  multiple,  incompatible  mainframe  systems  resulted  in  a 
networking  horror,  some  employees  were  operating  with  an  IBM 
terminal,  a  Burroughs  (Unisys)  terminal  and  a  PC  on  their  desks. 
The  network  had  to  be  completely  redesigned  during  the  transition, 
and  there  was  naturally  some  expense  connected  with  this.  (The  net 
effect  of  the  redesign  has  not  been  estimated,  but  the  desktop  real 
estate  has  most  certainly  been  reduced.) 

c.  Application  Custodian 

1-3)  As  mentioned  previously,  we  are  confronted  with  the  fact  that 
headcount  has  decreased  but  the  salary  budget  has  increased.  Systems 
personnel  famihar  with  UNIX,  Oracle  and  C  are  not  easy  to  find,  train 
or  retain.  The  long-term  impact  on  the  cost  of  systems  development, 
maintenance,  and  training  of  systems  personnel  is  not  known.  This  is 
one  of  the  most  crucial  issues  associated  with  downsizing  to  an  open 
systems  environment,  and  it  will  be  analyzed  in  more  detail  later  in  this 
report.  However,  there  are  two  observations  that  can  be  made  on  the 
current  case: 

•  INPUT  has  long  believed  that  productivity  in  the  systems  development 
(or  maintenance)  process  can  be  improved  only  by  having  fewer,  more 
highly  skilled  systems  personnel.  Therefore,  it  is  possible  that  staff 
reductions  and  higher  salaries  may  result  in  lower  costs. 

•  On  the  other  hand,  turnover  of  systems  personnel  is  extremely  costiy  in 
terms  of  development,  maintenance  and  training  expense.  The  subject 
company  may  be  fortunate  because  job  opportunities  are  restricted  due 
to  geographic  location;  but  finding,  training  and  keeping  high-quality 
personnel,  during  and  after  downsizing,  is  going  to  be  a  major  challenge 
for  most  companies. 
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4)  Passing  data  back  and  forth  among  the  Unisys  and  IBM  mainframes 
presented  file  transfer  and  data  quality  problems  that  should  actually  be 
improved  by  the  move  to  Oracle.  However,  the  re-engineering  of  the  old 
applications  did  not  make  exclusive  use  of  Oracle,  and  systems  integration 
is  still  not  complete  because  of  the  rapid  conversion  of  the  3090  systems. 
Perhaps  increased  effort  to  maintain  data  quahty  is  just  going  to  be  a  way 
of  life  in  tomorrow's  downsized  world. 

5-6)  The  decreased  headcount  and  increased  salary  level  phenomenon  has 
already  been  discussed.  (See  the  comments  under  Data  Center,  above.) 

7)  The  article  concerning  the  hiring  of  a  small  systems  integrator  that 
specializes  in  "mainframe  knockoffs  for  UNIX"  and  the  $250,000  conver- 
sion cost  that  was  cited,  prompted  INPUT  to  clarify  the  situation  with  the 
VP  of  IS  at  the  subject  company.  It  turns  out  that  the  systems  integration 
firm  provided  contract  programmers  for  the  conversion  effort,  but  it  was 
planned,  managed  and  implemented  primarily  with  in-house  personnel. 

The  total  transition  costs  for  the  downsizing  of  all  mainframe  applications 
has  been  roughly  estimated  at  $2  million.  It  was  cautioned  that  this 
estimate  was  extremely  rough  and  certain  trade-offs  (such  as  the  cost  of 
acquiring  a  manufacturing  system  for  the  IBM  mainframe  if  the  company 
had  not  downsized)  are  incorporated  in  estimating  the  downsizing  conver- 
sion costs.  We  understand  the  complexity  of  accounting  for  such  costs, 
and  are  sympathetic  to  those  who  cannot  estimate  transition  costs  in 
advance,  but  this  only  emphasizes  how  critical  transition  costs  are  in 
planning  a  downsizing  effort. 

d.  End  User 

1)  While  it  is  probable  that  additional  investment  has  been  made  in 
workstations,  it  has  to  be  less  costly  than  having  to  put  up  to  three  work- 
stations on  a  single  desk  to  tie  into  the  old  mainframe  environment.  We 
will  give  them  the  benefit  of  the  doubt  on  this  one  and  say  that  workstation 
costs  (and  the  desks  to  support  them)  will  decrease. 

2)  The  client/server  environment  places  additional  responsibility  for  data 
quality  on  end  users — where  it  belongs. 

3)  The  combination  of  re-engineering  and  systems  integration  that  is 
going  on  should  permit  end  users  to  be  more  productive,  and  it  is  reported 
that  new  applications  have  already  been  installed.  That  end  users  are  more 
productive  is  illustrated  by  the  fact  that  the  company  was  losing  money  at 
the  higher  levels  of  production,  but  is  now  making  money  at  the  lower 
levels.  This  can  only  be  accomplished  by  a  leaner,  more  productive  work 
force,  supported  by  improved  information  systems. 
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4)  This  transition  could  not  have  been  effective  without  consider- 
able effort  on  the  part  of  end  users.  Although  this  has  not  been 
quantified,  it  is  important  to  recognize  that  unless  end  users  are 
actively  involved  in  making  the  new  systems  work,  downsizing 
efforts  are  going  to  fail.  In  this  case,  the  effort  was  successful  and 
the  company  returned  to  profitability. 

This  case  study  company  was  selected  because  it  was  reported  that  an 
IBM  3090  mainframe  computer  being  used  for  commercial  applications 
had  been  quickly  and  cost  effectively  downsized.  Most  other  reported 
cases  of  IBM  mainframes  being  replaced  seemed  to  be  either  dedicated 
applications  (such  as  reservation  systems)  or  4381s.  Though  this  case 
study  has  been  well  publicized  as  a  3090  replacement  in  various  publica- 
tions, only  once  was  any  mention  made  of  the  fact  that  it  was  the  entry- 
level  model  of  the  3090,  a  120E,  that  had  been  replaced. 

Having  completed  these  case  studies,  we  fmd  that  organizations  that  have 
been  on  the  leading  edge  in  applying  information  technology  are  having 
difficulty  downsizing  their  large  IBM  mainframes — at  least,  as  expedi- 
tiously as  management  feels  this  should  be  done.  In  the  cases  of  the 
university,  railroad,  and  energy  company,  published  information  concern- 
ing downsizing  and  open  systems  seemed  to  be  influencing  (and  perhaps 
confusing)  management  thinking  on  the  subject. 

INPUT  decided  to  extend  a  content  analysis  of  trade  publications  begun  in 
the  original  research  for  this  downsizing  program  by  analyzing 
Computerworld  for  the  first  three  months  of  1992.  The  purpose  of  this 
analysis  is  to  determine  the  type  of  information  that  is  being  generally 
disseminated,  and  how  it  might  be  construed  by  the  casual  (or  even  not  so 
casual)  reader. 
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Published  Case  Studies 


The  strategic  case  studies  indicate  that  the  groundswell  for  downsizing  is 
being  supported  by  both  the  trade  press  and  the  popular  media.  It  is 
important  to  go  beyond  the  headlines  to  understand  what  is  really  happen- 
ing. INPUT  recognized  this  when  it  initiated  its  downsizing  program  last 
year,  and  did  a  literature  search  for  case  studies  that  yielded  some  surpris- 
ing results. 

Since  it  is  now  apparent  that  much  of  the  impetus  for  downsizing  is  being 
generated  by  published  case  studies,  INPUT  decided  to  supplement  this 
report  with  a  brief  review  of  downsizing  efforts  that  were  publicized  in  the 
first  three  months  of  1992. 

A  

The  Original  Case  Studies 

As  part  of  the  original  research  for  the  downsizing  program,  INPUT 
conducted  a  literature  search  for  appropriate  cases  studies.  These  case 
studies  were  used  as  examples  in  Putting  Downsizing  in  Perspective  [2]. 
They  were  used  to  make  the  following  points  in  that  study: 

•  Downsizing  to  PC  LANs  does  not  necessarily  result  in  reduced  systems 
staff  and  may  require  more  highly  skilled  (and  adaptable)  personnel. 

•  Shrink-wrapped  software  cannot  be  substituted  for  commercial  applica- 
tions without  considerable  systems  suppon  and  "programming." 

•  Downsizing  from  IBM  mainframes  to  RISC/UNIX-based  platforms  and 
commercially  available  DBMSs  (in  the  case  cited.  Pyramid  open  sys- 
tems and  an  Oracle  relational  DBMS)  can  result  in  substantial  cost 
savings  in  software  licenses  and  maintenance. 

•  Replacing  a  mainframe  computer  is  a  long,  involved  process,  and  most 
case  studies  are  published  before  the  mainframe  has  actually  been 
removed. 
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1.  Downsizing  Corporate  IS 

Let  us  begin  with  the  downsizing  of  the  Corporate  IS  function.  In  an 
article  entitled,  "When  the  CIO  becomes  expendable"  [4],  Computerworld 
reported  that  many  organizations  were  virtually  eliminating  the  corporate 
IS  function,  and  downgrading  the  CIO.  The  following  changes  in  tide  for 
the  "IS  chief  were  cited: 

•  At  Rubbermaid,  Inc: 

-  The  former  tide  was  Corporate  Vice  President,  MIS 

-  The  new  title  is  Manager,  Analysis  Planning 

•  At  United  Technologies: 

-  The  former  tide  was  Corporate  Vice  President,  IS 

-  The  new  title  is  Director,  Corporate  IS 

•  At  ASEA  Brown  Boveri: 

-  The  former  tide  was  Vice  President,  Information  Services 

-  The  new  tide  is  Director  Computer  and  AppUcations  Services 

•  Alco  Standard: 

-  The  former  title  was  Vice  President,  MIS 

-  The  new  tide  is  Director  MIS  &  Personnel 

There  is  no  indication  that  reducing  the  size  and  stature  of  the  corporate  IS 
function  was  accompanied  by  reduced  IS  costs.  In  fact,  there  is  growing 
awareness  that  the  preferred  architecture  for  downsizing  (client/server) 
may  not  cost  less,  and  there  was  an  article  in  the  same  issue  of 
Computerworld  that  cautioned  readers  in  this  regard.  [5] 

It  seems  obvious  that  corporate  downsizing  designed  to  empower  autono- 
mous business  units  can  have  an  adverse  impact  on  corporate  IS  depart- 
ments independent  of  the  downsizing  of  information  technology  itself. 

2.  Downsizing  Mainframes 

The  trend  toward  downsizing  and  open  systems  has  received  a  lot  of  type 
and  hype  from  the  trade  press.  Headlines  abound  supporting  the  delusion 
that  mainframes  and  proprietary  systems  are  headed  for  oblivion  because 
they  are  no  longer  competitive,  and  that  no  one  is  buying  proprietary 
systems  these  days.  When  INPUT  decided  to  look  behind  the  headlines 
and  do  a  content  analysis  of  these  case  studies,  it  managed  to  pull  together 
the  formidable  list  in  Exhibit  V-1. 
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EXHIBIT  V-1 


Downsizing  Case  Studies 


Company 

From 

To 

Replacement 

Cost  Benefits 

Ref. 

Northrup  King 

IBM  4381 

AS/400 

Completed 

"Easier  Devel" 

[18] 

Merrill-Lynch 

IBM  Mainframes 

Sun  Client/Server 

Never 

$2M  ~>  <$1  M 

[19] 

Revlon 

IBM  3090 

HP  Client/Server 

Planned 

Not  mentioned 

[20] 

TRW  Corp 

IBM  4381 

PC  Client/Server 

1991 

=63%  IS  Staff 

[17] 

Georgia-Pacific 

IBM  4300s 

AS/400S 

"Recently" 

Not  mentioned 

[17] 

Dakin,  Inc. 

Unisys  V  Series 

AS/400S 

1991 

-62%  IS  Staff 

[6] 

Motorola,  Inc. 

IBM  Mainframes 

RISC  -  MS  8000 

Planned 

<  IS  Investment 

[7] 

Moog  Automotive 

IBM  3083 J 

ASMOOs.PC  LANs 

Not  planned 

Faster  Dvlpmnt 

[8] 

Taylor  Medical 

IBM  System  36s 

PC  Client/Server 

Within  6  months 

"Response  time" 

[9] 

GTE  TeleOps 

IBM  &  MH  Mnfrms. 

HP  Client/Server 

Only  Honeywell 

Not  mentioned 

[10] 

Batesville  Co. 

IBM  4381 

UNIX-Server 

May  outsource 

-11%  IS  staff 

[11] 

GE  Capital  Corp 

IBM  3090 

"PC  front  ends" 

No  plan 

Not  mentioned 

[11] 

Breuners 

IBM  4381 

HP  Client/Server 

Planned 

-32%  IS  Staff 

[12] 

United  Airlines 

IBM  Mainframes 

PC  Client/Server 

No  plan 

Not  mentioned 

[13] 

Holiday  Inn 

IBM  Mainframes 

HP  Client/Server? 

No  plan 

Not  mentioned 

[14] 

Haggar  Co. 

IBM  3090 

AS/400S 

Within  18  months 

Not  mentioned 

[15] 

Orange  Cnty  FL 

IBM  4381 

PC  LAN 

"Within  months" 

-$800,000  (44%) 

[16] 

This  sample,  taken  mostly  from  Computerworld  (two  of  the  17  cases  came 
from  InformationWeek),  reveals  the  following: 

•  Fourteen  of  eighteen  systems  being  targeted  for  downsizing  are  IBM 
mainframe  systems.  (One  of  the  case  study  companies  had  both  IBM 
and  Honeywell  mainframes  installed,  so  there  were  18  targeted  systems 
in  the  17  companies.) 

-  Six  of  the  IBM  mainframes  were  specifically  designated  as  being  IBM 
4381s,  thus  confirming  INPUT'S  earlier  analysis  that  4381s  presented 
an  especially  attractive  target. 
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-  Four  of  the  IBM  mainframes  were  specifically  designated  as  30XX 
systems. 

-  Four  were  classified  as  IBM  mainft^mes  without  specific  designation 
and  could  be  either  4381s  or  3090s. 

-  The  remaining  four  case  study  companies  had  the  following  systems 
targeted  for  downsizing: 

•  A  Honeywell  mainframe 

•  Unisys  V  Series  Computers 

•  IBM  4300  series  (without  specific  designations) 

•  IBM  System  36s 

•  Analyzing  these  target  system  categories  by  their  replacement  status 
reveals  the  following  (see  Exhibit  V-2): 

-  Two  4381s  have  already  been  replaced,  and  three  are  planned  for 
replacement.  Only  one  of  the  case  study  companies  did  not  have  a 
replacement  plan,  and  that  one  said  it  might  have  to  outsource  any 
remaining  4381  workload.  The  4381,  positioned  at  the  bottom  of  the 
IBM  mainframe  escalator,  is  extremely  vulnerable  from  both  above 
and  below. 

-  The  four  companies  that  have  multiple  IBM  mainframes  installed 
(without  specific  model  designation),  have  no  current  plans  for  re- 
placement. It  is  probable  that  these  companies  are  planning  to  control 
mainframe  growth  by  downsizing  specific  applications  and  functions 
from  these  installed  systems. 

-  Two  of  the  four  IBM  30XX  systems  are  scheduled  for  replacement — 
one  within  18  months  and  the  other  in  2  years.  There  are  no  reported 
plans  to  replace  the  other  two. 

-  The  "other"  systems  are  a  curious  lot.  They  include  the  following: 

•  The  Unisys  V  Series  equipment  at  Dakin,  Inc.  was  evidently  re- 
placed last  year. 

•  Some  IBM  43XXs  at  Georgia  Pacific  were  replaced  "recently" — 
and  since  it  was  not  specifically  stated  that  they  were  4381s,  INPUT 
included  them  in  the  "other"  category. 

•  In  the  GTE  installation,  which  had  mixed  IBM  and  Honeywell 
mainframes,  the  Honeywells  are  scheduled  for  replacement,  but  it 
was  not  specified  when  this  would  occur. 
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EXHIBIT  V-2 


Systems  Targeted  for  Downsizing 
Replacement  Status 


IBM  4381 


IBM  Mainframe 


IBM  30XX 


Other 


mMmmmmmmm^ 


2 
2 


□  Replaced 
^  Planned 
El  Not  Planned 


•  Finally,  there  are  some  IBM  System  36s  at  Taylor  Medical  that  are 
scheduled  to  be  replaced  (by  client/server  PC  LANs)  within  the  next 
six  months. 

When  the  platforms  being  used  for  downsizing  are  analyzed  based  on 
their  success  in  replacing  the  targeted  systems,  we  find  the  following 
(Exhibit  V-3): 


-  AS/400s  have  replaced  an  IBM  4381,  the  Unisys  V  Series  equipment, 
and  the  Georgia  Pacific  IBM  43XXs  (in  other  words,  in  three  of  the 
four  cases  studies  where  actual  replacements  have  already  occurred). 
AS/400s  are  scheduled  to  replace  a  3090  within  the  next  18  months  at 
Haggar  Company.  However,  at  Moog  Automotive,  Inc.  it  is  not 
anticipated  that  an  aging  IBM  mainframe  will  be  replaced  any  time  in 
the  foreseeable  future,  even  with  a  combination  of  AS/400s  and  PC 
LANs. 
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Downsizing  Platforms 
Replacement  Status 


AS/400 


PC-C/S 


HP-C/S 


MS-8000 


Other 


2 
2 


□  Replaced 
^  Planned 

□  Not  Planned 


•ix-  2 


1 


2 

Number 


PC  LANs  (usually  in  a  client/server  architecture)  have  had  the  follow- 
ing impacts: 

•  They  have  succeeded  in  replacing  a  4381  at  TRW. 

•  They  are  scheduled  to  replace  another  4381  ("within  months")  at  the 
Orange  County,  Florida  Appraisers  Office,  and  they  are  scheduled 
to  replace  the  System  36s  at  Taylor  Medical  ("within  6  months"). 

•  There  is  no  plan  for  PC  LANs  to  replace  the  mainframes  they  are 
"front  ending"  at  GE  Capital  or  United  Airlines.  (However,  once 
again,  the  offloading  of  functions  could  be  used  as  a  means  of 
controlling  mainframe  growth.) 
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-  While  HP  client/server  systems  have  not  yet  replaced  any  mainframe 
systems  in  the  case  study  companies,  they  are  scheduled  to  do  so  in 
three  of  the  four  companies  in  which  they  are  being  used  as  downsiz- 
ing platforms.  (HP  appears  to  be  doing  very  well  in  the  downsizing 
arena — probably  as  a  result  of  being  an  early  convert  to  RISC  technol- 
ogy.) 

-  Motorola  has  a  highly  publicized  plan  to  replace  its  mainframe  com- 
puters (including  4381s)  with  client/server  networks  based  on  its  own 
RISC/UNIX  MS  8000  systems.  A  definite  plan  for  downsizing  IS 
budgets  has  been  established;  the  sale  of  a  4381  is  scheduled  to  be 
completed  this  year. 

-  The  "other"  downsizing  platforms  are  not  currently  scheduled  to 
replace  their  target  systems: 

•  The  Batesville  Casket  Co.  has  decided  that  it  will  downsize  to 
"UNIX- Servers"  but  still  may  have  to  outsource  some  of  its  IBM 
4381  work  load,  and  it  does  not  have  a  definite  replacement  plan. 
(This  information  was  gathered  from  an  article  entitied,  "IS  manag- 
ers admit  downsizing  fears"  [11];  which,  curiously  enough,  was  an 
outgrowth  of  the  recent  Downsizing  Expo.  Perhaps  the  downsizing 
bloom  is  already  off  the  rose.) 

•  While  Merrill  Lynch  is  enthusiastic  about  RISC  and  UNIX,  and  is 
currently  installing  a  lot  of  Sun  client/server  workstations,  when 
asked  when  it  might  replace  its  IBM  mainframes  the  answer  was 
essentially:  "never." 

In  these  case  studies,  the  AS/400  is  a  clear  winner  in  achieving  actual 
replacement  of  mainframe  systems.  It  is  probable  that  any  system  selhng 
at  a  rate  of  over  $1  billion  a  month  will  show  up  rather  well  in  practically 
all  market  segments,  but  when  one  considers  the  "handicaps"  this  IBM 
orphan  has  had  to  overcome,  it  is  indeed  quite  a  remarkable  performance. 
Consider  the  following: 

•  The  AS/400  is  a  proprietary  system  in  what  is  being  billed  as  an  open 
systems  world,  and  it  is  gaining  market  share. 

•  The  AS/400  architecture  builds  more  function  into  hardware  when  the 
latest  architectural  trend  is  to  build  stripped-down  RISC  engines  and 
leave  the  problems  to  systems  programmers. 

•  The  AS/400  has  been  virtually  ignored  by  the  trade  press,  consultants, 
and  competitors  throughout  much  of  its  life. 

•  In  fact,  the  AS/400  has  been  ignored  (and  misunderstood)  by  the  large 
systems  advocates,  PC  advocates  and  RISC  advocates  within  IBM. 
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*  IBM  has  been  slow  to  actively  promote  the  AS/400  as  a  distributed  data 
base  server  (for  which  it  is  so  well  suited) — much  less  as  a  downsizing 
platform  to  offload  (or  replace)  mainframes. 

However,  it  is  getting  increasingly  difficult  to  hide  the  success  of  the  AS/ 
400,  and  now  Business  Week  is  saying  that  maybe  IBM  will  become 
known  "as  the  AS/400  company  and  not  the  one  that  makes  mainframes 
and  PCs."  [21]  The  AS/400  certainly  cannot  be  ignored  as  a  downsizing 
platform,  and  this  research  confirms  that  opinion. 

As  mentioned  previously,  INPUT  research  disclosed  that  reduced  IS  and 
hardware  costs  are  ranked  highest  among  the  factors  prompting  downsiz- 
ing. Let's  see  what  the  published  case  study  companies  have  to  say  about 
the  cost  benefits  of  downsizing.  ° 

3.  Cost  Benefits  of  Downsizing 

The  most  prevalent  comment  the  case  study  companies  have  to  say  about 
the  cost  benefits  of  downsizing  is.. .nothing!  Exhibit  V-4  shows  that 
seven  of  the  seventeen  companies  have  nothing  to  say  about  cost  savings, 
and  it  can  only  be  concluded  that  there  haven't  been  any,  because  any  IS 
executive  who  is  saving  his  company  money  these  days  is  going  to  be 
more  than  willing  to  brag  about  it  in  the  press. 


EXHIBIT  V-4 


Benefits  Mentioned 


Performance-! 


IS  Investment 


(5.9%) 


Easy  Development 

(11.8%) 


IS  Staff 
(23.5%) 


No  Mention 


$  Savings 
(11.8%) 


(41.1%) 
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A  more  detailed  look  at  the  individual  companies  reveals  the  following: 

•  The  seven  companies  (41%)  that  did  not  mention  cost  benefits  are  as 
follows: 

-  Revlon  is  on  a  crash  program  to  migrate  its  IBM  3090  mainframe  to 
an  HP  client/server  architecture  in  two  years.  It  is  outsourcing  its 
mainframe  processing  to  Arthur  Andersen,  and  cost  benefits  antici- 
pated from  this  downsizing  effort  were  not  announced.  However,  the 
crash  program  is  being  undertaken  because  the  President  of  Revlon 
North  America  did  not  want  to  get  involved  in  a  "five-year  deal" — 
which  indicates  he  has  some  sensitivity  to  the  transition  costs  of  such 
a  radical  architectural  change.  There  is  no  question  that  a  substantial 
initial  investment  will  be  required. 

-  Georgia-Pacific,  which  replaced  obsolete  IBM  4300  midrange  sys- 
tems with  AS/400s,  will  not  even  talk  about  the  cost  of  the  transition. 
The  costs  were  said  to  be  "secret."  This  makes  the  important  point 
that  replacing  obsolete  systems  with  new  technology  usually  requires 
additional  investment  regardless  of  whether  the  systems  are  being 
downsized  to  more  cost-effective  platforms. 

-  GTE  also  failed  to  mention  any  cost  benefits  associated  with  the 
replacement  of  its  Honeywell  mainframe  with  a  network  of  HP  UNIX 
systems.  It  is  probable  that  the  payback  here  will  be  in  controlling  the 
growth  of  the  IBM  mainframes  that  will  remain,  and  that  the  addi- 
tional investment  will  be  recovered  over  the  long  run. 

-  GE  Capital  Corporation  does  not  intend  to  replace  its  IBM  3090  but 
will  downsize  (offload)  some  processing  to  "PC  front  ends."  Compa- 
nies that  really  understand  information  system  costs  seldom  make 
snap  judgements  about  cost  benefits  from  new  technologies.  GE  does 
understand  the  complexity  of  shifting  IS  costs,  and  it  brought  some 
realism  to  the  Downsizing  Expo  by  not  making  any  outrageous  claims 
for  what  it  is  doing. 

-  United  Airlines  is  similar  to  GE.  It  is  a  knowledgeable  company  that 
is  taking  advantage  of  new  technology  in  the  normal  course  of  busi- 
ness. It  will  not  get  caught  up  in  the  hoopla  of  new  technology  for 
technology's  sake,  and  it  is  too  experienced  to  believe  that  MIPS 
ratings  or  ease  of  use  drop  directly  to  the  bottom  line  of  information 
systems  costs.  It  is  careful  about  cost  control  (it  is  instalhng  Phillips 
diskless  workstations),  but  it  is  not  making  extravagant  claims  about 
benefits. 
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-  Holiday  Inn  is  installing  a  UNIX-based  network  (probably  incorporat- 
ing HP  client/servers)  that  will  cost  approximately  $60  million.  It  will 
handle  front-desk  applications  and  reservations,  and  it  is  designed  to 
provide  competitive  advantage  by  giving  customers  better  service. 
Mainframes  are  not  scheduled  to  disappear,  and  Holiday  Inn  isn't 
claiming  any  specific  cost  benefits. 

-  Haggar  Apparel  Co.  is  planning  to  replace  an  IBM  3090  computer 
with  AS/400s  within  18  months,  but  it  isn't  making  any  claims  about 
the  cost  benefits  except  to  state  that  its  current  systems  were  aging  and 
that  the  availability  and  quality  of  packaged  software  to  integrate  and 
manage  the  conversion  of  its  "wide  array  of  existing  home  grown 
applications"  swung  it  to  the  AS/400  rather  than  going  with  UNIX- 
based  software  for  the  RISC  System/6000. 

•  Four  companies  said  that  reduction  in  IS  staff  was  a  cost  benefit  associ- 
ated with  downsizing.  We  will  not  dispute  that  it  is  possible  to  reduce 
the  central  IS  staff  by  downsizing  to  smaller,  more  cost-effective  sys- 
tems. However,  we  do  caution  that  such  numbers  can  be  misleading 
when  user  organizations  are  being  empowered  with  responsibility  for 
their  own  information  systems.  The  legerdemain  of  finance  may  show 
decreased  IS  budgets,  but  the  actual  expense  of  information  systems 
activities  may  be  increasing.  However,  even  if  we  accept  the  IS  staff 
reductions  at  face  value,  examination  of  the  individual  cases  raises  some 
additional  questions. 

-  Corporate  Headquarters  of  TRW  has  some  rather  impressive  numbers 
as  a  result  of  replacing  its  IBM  4381  with  client/server  PC  networks 
and  "midrange  computers."  (INPUT  credited  this  replacement  to  PC 
networks,  but  we  suspect  the  midrange  computers  may  be  AS/400s.) 

'  The  IS  department  was  slashed  from  135  people  to  50 — a  reduction 
of  63%. 

•  The  corporate  IS  budget  was  reduced  from  $17  million  to  $7  mil- 
lion— a  reduction  of  59%. 

•  The  cost  of  managing  human  resources,  which  at  one  time  reached 
$2.5  million  per  year,  is  now  only  $300,000 — a  reduction  of  88%. 
(This  is  a  suspect  number  that  probably  has  more  to  do  with  ac- 
counting for  application  development/acquisition  and  maintenance 
than  it  does  with  operational  costs.) 

•  And,  it  is  projected  that  the  cost  of  preparing  a  paycheck  will  drop 
from  $1.20  to  50  or  60  cents  by  the  end  of  this  year. 

•  Generally  speaking,  these  numbers  (except  as  noted)  are  not  terribly 
surprising.  The  4381  is  a  prime  target  for  downsizing. 
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-  Dakin,  Inc.  saw  its  sales  drop  from  $200  million  to  $75  million  and 
managed  to  decrease  its  IS  staff  from  32  to  12  (a  reduction  of  62%)  by 
replacing  a  Unisys  V  series  mainframe  with  an  IBM  AS/400  with  off- 
the-shelf  financial  software.  Under  the  circumstances,  we  do  not  find  - 
the  staff  reduction  surprising  except  that  the  percentage  reduction  is 
practically  identical  to  those  reported  by  TRW  for  a  much  larger  IS 
organization  (see  above),  and  it  is  also  directly  proportional  to  the 
drop  in  Dakin 's  sales. 

-  At  Batesville  Casket  Company,  putting  the  responsibility  for  ad  hoc 
reports  out  in  the  end-user  departments  freed  up  four  of  the  35  IS 
department  employees  (an  11%  reduction)  for  other  work.  Though 
this  will  not  result  in  actual  cost  savings,  it  is  viewed  by  the  IS  depart- 
ment as  "getting  four  guys  for  free" — so  INPUT  included  it  as  a 
benefit  of  downsizing  functions  from  the  mainframe  to  the  desktop. 
Batesville  can  be  credited  with  a  succinct  summary  of  the  alternatives 
for  4381  users:  "We'll  either  learn  to  downsize  or  we'll  outsource." 

-  Breuners  (a  home  fumishing  chain)  has  reduced  its  central  IS  staff 
from  47  to  32  (a  32%  reduction),  even  before  its  4381  has  been  re- 
placed. However,  this  has  not  been  an  easy  transition,  and  all  of  the 
staff  reductions  have  not  necessarily  been  desirable.  Breuners  is  still 
in  the  process  of  re-engineering  its  mainframe  applications  by  rewrit- 
ing them  in  C  for  an  HP  client/server  network.  This  shift  was  man- 
dated by  the  president  of  the  company  (who  happens  to  be  a  recent 
Harvard  Business  School  graduate)  despite  the  fact  that  substantial 
"up  front  costs  are  being  incurred."  Among  the  personnel  impacts  are 
the  following: 

•  A  $1,000  to  $2,000  "investment"  per  programmer  to  train  them  in 
the  new  technology  (this  figure  probably  does  not  include  lowered 
programmer  productivity  during  the  transition). 

•  While  only  a  few  IS  employees  quit  because  of  the  transition,  one 
was  the  DB2  data  base  administrator  (this  could  be  considered  either 
positive  or  negative,  depending  upon  one's  perspective). 

•  Some  of  the  newly  trained  C  (UNIX)  programmers  have  already  left 
the  company  for  "opportunities"  in  other  organizations. 

•  The  migration  began  two  years  ago  and  still  isn't  complete,  yet  it  is 
stated  that  the  "speed  of  Breuners'  shift  into  downsizing  has  stunned 
some  observers." 
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•  Perhaps  most  significant  is  the  observation  of  Breuners'  president 
that  the  "patchwork  of  code"  that  had  evolved  on  the  4381  was 
"determining  how  the  business  was  run,  rather  than  the  other  way 
around."  When  all  is  said  and  done,  one  doesn't  have  to  worry  too 
much  about  cost/benefit  analysis  when  the  re-engineering  of  obso- 
lete applications  is  the  most  important  factor  to  management. 

•  Only  two  of  the  seventeen  companies  mentioned  actual  cost  savings 
from  their  downsizing  efforts,  and  the  figures  were,  at  best,  vague.  For 
example: 

-  At  Merrill  Lynch,  one  "high-powered  trading  unit"  cited  reduced 
"computing  cycle  costs"  from  $2  million  a  year  down  to  less  than  $1 
million,  and  indicated  that  "This  is  the  flavor  of  what  gains  will  be 
realized  with  UNIX."  There  seems  to  be  considerable  confusion  here 
about  the  role  of  hardware,  systems  software,  applications,  and  main- 
frame billing  algorithms  in  determining  how  much  one  pays  for 
"computing  cycles."  In  addition,  it  isn't  as  if  mainframes  are  going  to 
disappear — Merrill  Lynch  will  retain  eight  IBM  mainframes  in  two 
data  centers  to  serve  as  super  data  base  servers,  and  to  handle  "the 
heavy  duty  processing  of  month-end  statements  and  high  volume 
transactions."  No  statement  is  made  concerning  the  overall  cost  of  the 
information  technology  infrastructure,  which  has  unquestionably  gone 
up  with  the  investment  in  expensive  (though  powerful)  workstations, 
and  there  are  indications  that  downsizing  at  Merrill  Lynch  was 
prompted  primarily  by  the  desire  to  give  user  departments  applications 
control  so  they  won't  have  to  "depend  on  the  systems  group." 

-  Then  there  is  the  recent  case  of  the  Orange  County,  Florida  Appraisers 
Office,  which  states  that  it  has  already  "cut  some  $800,000  out  of  $1.8 
million  of  operating  and  maintenance  costs  (a  44%  reduction)  even 
before  it  replaced  the  IBM  4381  with  a  PC  LAN  network.  After  the 
4381  is  removed,  it  is  estimated  another  $400,000  will  be  saved  for  a 
total  operating  and  maintenance  cost  reduction  of  67%.  It  is  probable 
that  some  creative  and  speculative  accounting  is  being  done  here,  but 
this  case  does  emphasize  the  vulnerability  of  the  low  end  of  the  IBM 
mainframe  line.  Consider  the  following: 

•  Fourteen  of  the  19  nodes  in  the  upsizing  case  study  presented  earlier 
(Exhibit  III-2)  achieved  operating  and  maintenance  cost  savings 
exceeding  44%,  which  not  only  verifies  the  fact  that  the  downsizing 
cost  savings  may  be  reasonable,  but  also  demonstrates  that  the  4381 
is  vulnerable  to  "upsizing"  as  well. 

•  Even  the  67%  cost  saving  figure  is  not  entirely  unreasonable,  since 
two  of  the  19  nodes  in  the  upsizing  case  study  exceeded  that  figure 
by  replacing  the  low  end  of  the  mainframe  line  with  larger  systems. 
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•  Orange  County  also  pointed  out  that  its  PC  LAN  network  provided 
redundancy  (servers  were  backed  up),  reliability  with  cheap 
uninterruptible  power  supplies,  cheaper  space,  and  cheaper  DASD 
than  the  4381 — precisely  the  advantages  identified  in  the  upsizing 
case  study. 

•  It  is  possible  to  depict  downsizing  and  upsizing  as  a  bell  curve  with 
PCs  on  the  left,  the  4381  at  the  apex,  and  Enterprise  9000s  on  the 
right;  with  the  x-axis  representing  computer  power  and  the  y-axis 
representing  operating  and  maintenance  cost.  (This  diagram  will  be 
presented  and  described  in  more  detail  later  in  this  report.) 

•  Two  of  the  seventeen  case  study  companies  (Northrup  King  Co.  and 
Moog  Automotive)  emphasized  easier,  faster  applications  development 
as  a  primary  benefit  of  downsizing.  Analysis  shows  that  everything  is 
relative. 

-  Northrup  King  has  already  replaced  a  4381  with  an  AS/400  and  states 
that  easier  development  was  an  added  bonus  in  the  downsizing  effort. 

-  Moog  Automotive  has  downsized  applications  from  an  IBM  3081 J  to 
both  AS/400  and  client/server  PCs  (386-based  PC  clients,  and 
Parallan  Computer  servers),  and  it  finds  that  development  and  deploy- 
ment of  applications  on  the  client/server  PCs  are  much  faster  than  on 
the  AS/400.  Moog  stated  that  what  would  take  120  days  in  the  AS/ 
400  environment  takes  only  a  week  on  the  PCs. 

-  Ease  of  programming  and  use  obviously  depend  upon  both  perspec- 
tive and  the  applications  being  developed  and/or  re-engineered. 

•  Taylor  Medical,  Inc.  is  the  only  organization  to  emphasize  improved 
performance  of  its  system  (in  terms  of  turnaround  time),  and  this  down- 
sizing effort  is  important  from  several  points  of  view. 

-  The  downsizing  effort  was  directed  toward  a  network  of  System/36s 
that  were  overloaded  because  of  company  growth. 

-  AS/400s,  which  could  have  provided  an  easy  upgrade  path,  were  ruled 
out  because  Taylor  did  not  want  to  lock  itself  into  a  proprietary  envi- 
ronment. 

-  The  key  to  success  in  making  the  shift  was  the  conversion  of  RPG  III 
applications  from  the  System/36s  to  a  client/server  PC  environment 
based  on  two  SystemPro  file  servers,  and  six  33-MHz  I486  DeskPros 
from  Compaq  Computer  Co. 
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-  The  solution  to  the  conversion  problem  was  a  compiler  and  operating 
environment  called  Baby/4XX  from  Cahfomia  Software  Products, 
Inc.  It  permits  Taylor  Medical  to  run  its  System/36  RPG  III  applica- 
tions on  its  PC  network. 

-  The  fact  that  turnaround  time  for  accounts  receivable  has  dropped 
from  eight  hours  on  the  System/36s  to  30  minutes  on  the  new  system 
is  probably  a  result  of  replacing  obsolete  systems  with  new  network 
technology,  but  the  Baby/4XX  software  product  is  important  because 
it  should  provide  the  ability  to  port  RPG  III  applications  from  the  AS/ 
400  as  well.  This  type  of  cost  comparison  will  be  of  increasing 
importance  as  downsizing  proceeds  in  the  1990s.  (INPUT  intends  to 
prepare  a  report  on  downsizing  methodologies  as  part  of  the  downsiz- 
ing program.) 

•  Motorola,  Inc.'s  General  Systems  Sector  (GSS),  which  consists  of  two 
rapidly  growing  cellular  businesses  and  Motorola's  computer  group,  has 
set  an  objective  of  reducing  IS  expense  to  less  than  1%  of  sales  by  1993. 
At  present.  Motorola's  overall  IS  expense  is  2.8%  of  sales,  and  that  of 
GSS  is  1.4%.  GSS's  downsizing  of  the  IS  budget  is  based  upon  down- 
sizing IBM  mainframe  applications  to  Motorola's  own  UNIX/RISC- 
based  MS  8000s. 

-  Motorola  stated  that  one  of  the  main  reasons  the  objective  may  be  met 
is  the  availability  of  "off-the-shelf  software  applications  and  develop- 
ment environments"  in  the  UNIX  world.  At  present,  data  base  soft- 
ware from  both  Oracle  and  Informix  Software  is  being  evaluated  and 
no  date  has  been  set  for  replacement  of  the  mainframe  systems. 

-  Obviously  a  lot  depends  upon  the  quality  of  the  off-the-shelf  software 
Motorola  is  depending  upon.  But  GSS  certainly  has  a  good  shot  at 
achieving  its  object  of  reducing  its  IS  expense  to  1%  of  sales — inter- 
nal transfer  rates  can  work  wonders  for  computer  companies  in  this 
regard.  However,  it  is  INPUT'S  observation  that  practically  all  mini- 
computer and  PC  companies  still  have  IBM  mainframes  installed. 

-  Motorola's  arbitrary  goal  of  reducing  IS  expense  to  less  than  1%  of 
sales  reminds  us  that  there  is  no  significant  correlation  (either  positive 
or  negative)  between  investment  in  information  technology  and 
corporate  performance.  This  obviously  means  that  companies  invest- 
ing more  in  information  technology  do  not  necessarily  obtain  the 
"competitive  advantage"  promised  by  computer  vendors.  On  the 
other  hand,  it  is  probably  unreasonable  to  expect  that  reduced  expen- 
ditures on  information  technology  will  drop  straight  to  the  bottom 
line. 
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Analysis  of  these  published  case  studies  tends  to  support  INPUT'S  re- 
search in  which  it  found  that  organizations  with  downsizing  efforts  actu- 
ally under  way  did  not  consider  lower  IS  or  hardware  costs  to  be  among 
the  most  important  benefits  expected,  even  though  these  factors  were  the 
primary  factors  prompting  the  downsizing  efforts.  [2] 

In  addition,  analysis  of  these  "success  stories"  reinforces  what  was  learned 
from  the  strategic  case  studies:  there  is  currently  no  easy  way  out  of  the 
large  mainframe  cost  trap. 

However,  an  executive  casually  reading  through  these  articles  as  they 
appear  would  certainly  get  the  impression  that  IBM  mainframes  are  being 
replaced  at  a  prodigious  rate  with  cheap  hardware  and  software.  Execu- 
tives don't  discriminate  very  easily  among  computer  models,  and  it  is 
understandable  that  a  Georgia  Pacific  executive  wouldn't  realize  that 
successfully  "downsizing"  43XX  systems  to  AS/400s  isn't  quite  the  same 
as  replacing  a  3090,  Model  600.  (In  fact,  it  is  possible  that  Georgia  Pa- 
cific may  have  actually  been  "upsizing"  when  it  installed  AS/400s,  but 
corporate  executives  and  newspaper  editors  can't  be  expected  to  know 
that.)  However,  when  this  executive  mentioned  his  downsizing  success 
story  in  a  board  of  directors  meeting,  he  certainly  put  the  VP  of  MIS  for 
the  railroad  under  considerable  pressure. 

There  is  a  big  credibility  gap  on  all  sides  of  this  information  technology 
revolution,  but  the  fact  remains  that  it  all  gets  back  to  a  question  of  costs: 
not  only  the  relative  costs  of  various  technological  "solutions,"  but  the 
fundamental  costs  of  humans  versus  machines  in  the  work  place.  That  is 
what  downsizing  is  all  about. 
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Analysis  of  Case  Studies 


The  downsizing  phenomenon  is  a  manifestation  of  IBM's  loss  of  control 
over  the  information  technology  innovation  process.  Specifically,  the 
diffusion  of  new  technology  is  no  longer  dependent  upon  IBM's  "bless- 
ing" as  it  was  just  a  few  years  ago.  There  were  those,  even  in  IBM,  who 
intuitively  knew  that  this  day  would  come,  but  most  IBM  planners  re- 
mained (and  perhaps  remain)  in  a  state  of  abject  denial  about  the  vulner- 
ability of  the  IBM  mainframe  product  line.  This  attitude  was  summed  up 
by  an  IBM  employee  interviewed  by  INPUT  in  the  early  1980s.  He  said: 
"We  have  made  a  lot  of  money  on  mainframes  for  a  long  time,  and  there 
are  those  around  here  (IBM)  who  think  it  can  go  on  forever." 

IBM  is  still  "making  a  lot  of  money  on  mainframes,"  but  the  end  is  clearly 
in  sight.  Suddenly,  it  seems  no  one  is  satisfied  with  mainframe  hardware/ 
software  costs.  Perhaps  the  end  of  the  golden  era  of  mainframes  could 
have  been  predicted  using  fuzzy  arithmetic  and  Rene  Thom's  concept  of 
catastrophe  [21],  but  it  is  doubtful  that  such  a  forecast  would  have  altered 
IBM's  business  plan  all  that  much.  IBM  is  in  the  mainframe  trap  along 
with  its  customers.  How  do  you  gracefully  adjust  your  business  strategy 
from  a  high-margin  market  you  dominate  to  a  cutthroat  commodity  mar- 
ket— even  if  you  know  that  change  is  inevitable? 

The  answer  is  you  can't  do  it  gracefully,  and  IBM  has  stumbled  badly  and 
actually  contributed  to  the  factors  prompting  downsizing. 

A  

Factors  Prompting  Downsizing 

The  primary  factors  prompting  downsizing  are  the  perceived  hardware/ 
software  expense  and  complexity  of  the  IBM  mainframe  product  line — 
especially  at  the  low  end,  which  stands  out  like  a  sore  thumb. 

INPUT  was  reminded  of  catastrophe  theory  when  it  did  a  chart  of  the 
relative  replacement  vulnerability  of  various  IBM  hardware/software 
platforms  to  both  downsizing  and  upsizing  based  on  analysis  of  the  case 
studies  in  this  repon.  (See  Exhibit  VI- 1.) 
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Relative  vulnerability  was  determined  based  on  actual  replacements, 
hardware/software  costs,  and  perceived  ease  of  replacement  as  demon- 
strated by  the  case  studies.  When  this  rough  analytical  model  was  com- 
pleted, the  roM  4381  and  smaller  models  of  the  ES  3090/9000,  were 
positioned  near  what  resembled  a  cusp  (one  of  several  elementary  catas- 
trophes) where  the  upsizing  and  downsizing  curves  meet.  While  these 
curves  were  not  mathematically  determined,  they  certainly  depict  a  serious 
discontinuity  in  the  IBM  product  line,  and  that  is  what  catastrophe  theory 
is  all  about. 
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The  analysis  supporting  the  chart  is  as  follows: 

•  The  upsizing  case  study  at  the  beginning  of  this  report  demonstrated  that 
significant  cost  savings  can  be  achieved  by  replacing  smaller  main- 
frames and  consolidating  into  large  data  centers.  The  cost  savings 
associated  with  upsizing  within  the  mainframe  product  line  are  based  on 
hardware  price/performance,  more  effective  hardware/software  use, 
fewer  operating  and  support  personnel,  and  less  operating  and  environ- 
mental overhead. 

•  Because  large  mainframes  are  more  cost  effective  than  their  smaller 
brothers  and  sisters,  they  are  not  as  attractive  as  targets  for  downsizing. 
(In  addition,  application  conversion  problems  associated  with  large 
mainframes  make  actual  replacement  difficult  at  best.) 

•  The  published  case  studies  show  that  4381s  and  low-end  3090  main- 
frames are  the  most  vulnerable  to  replacement  through  downsizing. 
Since  these  same  platforms  are  also  vulnerable  to  upsizing,  the  disconti- 
nuity in  the  IBM  product  line  becomes  apparent. 

•  The  sharp  drop  in  relative  costs  when  downsizing  low-end  mainframes 
to  minicomputers  (AS/400),  RISC  workstations  (RS/6000),  and/or 
personal  computers  (PS/2)  is  based  in  large  part  on  the  same  factors  that 
make  upsizing  within  the  mainframe  product  line  so  attractive.  How- 
ever, there  are  additional  perceived  benefits  from  downsizing  associated 
with  hardware/software  ease  of  use  and  application  availability  and/or 
development. 

•  Price/performance  of  personal  computers  also  makes  minicomputers  and 
RISC  workstations  potentially  vulnerable  to  downsizing. 

However,  the  pecking  order  among  minicomputers,  RISC  workstations, 
and  personal  computers  (especially  on  the  server  side  of  the  client/server 
architecture)  has  yet  to  be  determined.  Nonetheless,  it  is  safe  to  state  that 
it  will  be  determined  by  factors  other  than  raw  hardware  price/perfor- 
mance. 

B  

Factors  Inhibiting  Downsizing 

There  seem  to  be  two  primary  factors  inhibiting  downsizing:  1)  the 
number,  size  and  complexity  of  installed  mainframe  applicacions  and  data 
bases;  and  2)  the  belief  on  the  part  of  IS  management  that  all  of  this  size 
and  complexity  is  necessary  (or,  at  least,  unavoidable). 
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The  first  factor  raises  two  questions: 

•  How  can  we  convert  (downsize)  these  applications  and  data  bases  to 
more  cost-effective  platforms?  (Is  downsizing  possible?) 

•  How  much  will  it  cost  to  make  this  transition?  (Is  downsizing  really 
worth  it?) 

As  the  case  studies  have  shown,  these  are  not  always  easy  questions  for  IS 
management  to  answer. 

The  second  factor  also  raises  two  questions: 

•  Are  mainframe  applications  enabling  tools  (and  in  this  we  include 
operating  systems  as  well  as  DBMSs  and  languages)  necessary  "solu- 
tions" for  the  development  of  complex  mainframe  applications  or  part  of 
the  complexity  problem? 

•  Are  the  "investments"  in  mainframe  applications  and  data  bases  corpo- 
rate assets  or  liabilities  at  the  present  time? 

These  are  questions  that  some  IS  managers  do  not  really  want  to  address 
or  even  acknowledge — it  is  unthinkable  that  everything  they  have  worked 
so  hard  to  build  may  be  more  problem  than  solution. 


Architecture  and  Applications  Selection 

IBM's  System  Network  Architecture  (SNA)  is  the  reason  mainframes  are 
vulnerable  to  downsizing.  That  architecture  puts  the  mainframe  at  the 
center  of  the  data  processing  universe,  and  IS  management  appears  to  have 
built  a  "big  blue  hole"  that  has  gobbled  up  data  from  throughout  the 
organization  and  made  it  increasingly  difficult  for  necessary  operating  and 
management  information  to  "escape."  That  is  the  trap  in  which  IS  man- 
agement finds  itself  at  the  present  time. 

1.  SAA  and  Downsizing 

IBM's  Systems  Application  Architecture  (SAA)  has  been  described  as  its 
plan  for  downsizing.  SAA  was  the  direct  result  of  customer  dissatisfaction 
with  the  "big  blue  hole"  created  by  SNA.  It  is  IBM's  published  plan  for 
how  data  and  applications  should  be  distributed  over  networks.  By  exam- 
ining this  plan,  it  is  possible  to  determine  the  vulnerability  of  SAA  to  other 
downsizing  initiatives. 
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INPUT  has  taken  its  view  of  "S AA  distributed  processing"  from  an  article 
by  that  name  in  the  IBM  Systems  Journal.  [28]  The  article  was  written  by 
Dr.  Allan  J.  Scherr,  whose  experience  with  computer  networking  and 
multi-user  systems  goes  back  to  the  seminal  work  he  did  on  performance 
measurement  of  timesharing  systems  in  the  1960s.  We  mention  this 
because  of  the  importance  of  performance  measurement  (and  prediction) 
when  downsizing  to  client/server  LANs.  Dr.  Scherr  concludes  that  "dis- 
tributed processing  configurations"  will  be  determined  by  two  factors: 
organization  size  and  degree  of  data  sharing  (see  Exhibit  VI-2). 


EXHIBIT  Vi-2 
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He  concludes  the  following: 

•  That  client/server  LANs  (as  we  now  know  them)  are  appropriate  for 
small  organizations  that  require  a  minimum  of  data  sharing. 

•  That  small  organizations  with  a  high  degree  of  data  sharing  are  best 
served  by  a  "small  DP  center"  with  nonprogrammable  workstations. 

•  That  large  organizations  with  limited  data  sharing  will  typically  have 
.  networked  minicomputers  and  distributed  data  bases  supporting 

nonprogrammable  workstations  either  directly  attached  to  the  minis  or 
on  LANs. 

•  That  large  organizations  with  a  high  degree  of  data  sharing  will  have  a 
large  "central  DP  complex"  with  mainframes  and  central  data  bases  that 
will  serve  LANs  (with  non-programmable  workstations)  through  remote 
"communication  processors." 

These  are  obviously  the  extreme  cases  because  in  an  earlier  IBM  Systems 
Journal  article.  Dr.  Scherr  made  a  convincing  argument  that  mainframes, 
minicomputers  and  personal  computers  would  all  have  important  roles  to 
play  in  most  business  organizations  of  any  significant  size.  [29]  However, 
the  heavy  emphasis  upon  nonprogrammable  workstations  in  these  configu- 
rations is  certainly  enough  to  raise  questions  about  whether  IBM's  view  of 
downsizing  corresponds  with  that  of  the  rest  of  the  world.  Fortunately,  the 
body  of  the  article  points  out  that: 

"The  first  mode  of  distributed  processing  is  local  processing,  where  the 
application  and  data  are  in  the  same  node,  which  is  either  the  user's 
intelligent  (programmable)  workstation  itself  or  the  node  closest  to  the 
user's  workstation.  In  a  well-designed  distributed  system,  the  local  data 
processing  mode  is  usually  prevalent,  because  it  offers  the  best  perfor- 
mance and  lowest  cost."  [28] 

So,  SAA  (or  at  least  Dr.  Scherr)  has  noble  objectives:  migration  of  both 
applications  and  data  to  the  most  cost-effective  level. 

2.  Application  and  Data  Placement 

Dr.  Scherr  reached  his  conclusion  that  "a  well-designed  distributed  sys- 
tem" usually  places  emphasis  on  the  local  data  processing  node  based  on  a 
model  for  determining  the  proper  placement  of  applications  and  data  in  a 
network.  The  model  measures  message  traffic  between:  users  and  applica- 
tions, applications  and  data  bases,  and  application  programs.  Then  cost 
data  are  developed  showing  overhead  in  terms  of  response  time,  cycles 
executed  on  the  various  processors,  and  communications  costs  to  imple- 
ment the  message  traffic.  When  these  are  used  to  compute  the  specific 
communication  costs  for  various  placements  of  programs  and  data.  Dr. 
Scherr  states  that  three  "facts"  emerge: 
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1)  Communication  within  a  data  processing  node  is  significantly  more 
efficient  (cheaper)  than  communication  from  node  to  node. 

2)  The  traffic  between  applications  and  data  is  significantly  higher  than 
the  traffic  between  users  and  appUcations. 

3)  The  cost  of  communication  between  two  processors  in  the  same 
building  or  campus  (using  local-area  networking  facilities)  is  significantly 
lower  than  communication  between  buildings  or  campuses  requiring  wide- 
area  networking  facilities. 

These  "facts"  lead  to  the  conclusion  that  "users  and  the  applications  and 
data  they  use  should,  whenever  possible,  be  placed  in  the  same  data 
processing  node."  In  other  words,  most  applications  are  suitable  for 
downsizing  provided  data  can  be  distributed  along  with  the  applications 
programs. 

Dr.  Scherr  thus  made  a  convincing  argument  for  downsizing  at  the  time 
SAA  was  announced.  He  proved  what  most  corporate  executives  and  IS 
managers  now  intuitively  "know" — large  mainframes  and  centralized  data 
bases  are  not  cost  effective  for  most  applications.  Thus  SAA  can  fairly  be 
stated  to  be  IBM's  "plan"  for  downsizing.  The  problem  has  been  that 
there  is  limited  understanding  and/or  acceptance  of  SAA  among  the  IBM 
customer  base  (much  less  the  rest  of  the  world),  and  progress  in  imple- 
menting SAA  has  been  excruciatingly  slow. 

While  there  isn't  a  great  deal  of  talk  about  SAA  these  days,  the  AS/400  is 
emerging  as  a  leading  downsizing  platform,  and  OS/2  2.0  has  exceeded 
IBM's  expectations  since  it  was  introduced  in  March  1992.  (It  was  re- 
cently reported  that  700,000  copies  of  OS/2  2.0  had  been  shipped  in  the 
first  three  months  of  availability.  [30]) 

a.  Managing  Price/Performance  in  a  Client/Server  Environment 

Dr.  Scherr' s  model  for  the  cost-effective  distribution  of  programs  and  data 
in  networks  provides  an  objective  basis  for  selecting  applications  to  be 
downsized,  and  he  implies  that  empirical  research  supports  the  "fact"  that 
both  programs  and  data  should  normally  be  kept  as  close  to  the  user  as 
possible.  While  this  all  supports  the  general  trend  toward  downsizing  of 
mainframe  applications.  Dr.  Scherr  goes  on  to  point  out  that  the  use  of 
multiple  data  processing  systems  within  the  enterprise  "creates  the  need 
for  system  management  facilities  designed  for  a  distributed  environment," 
and  he  concludes  that  "most  enterprises  will  want  to  manage  the  network 
of  systems  as  a  single  entity." 
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b.  Centralization  versus  Decentralization  of  Function 

He  then  outlines  the  various  aspects  of  network  management  that  can  be 
either  centralized  or  decentralized  depending  upon  the  requirements  of  the 
individual  enterprise.  They  are  as  follows: 

1.  Administration  of  data,  data  bases,  security,  user  authorization, 
accounting,  etc. 

2.  Operation  of  individual  systems  and  the  network  itself 

3.  Systems  programming,  including  the  control  and  distribution  of  fixes 
and  new  versions 

4.  Application  programming,  including  the  control  and  distribution  of 
fixes  and  new  versions 

5.  Problem  determination 

6.  Service  of  hardware,  software  and  communications 

The  centralization  of  these  functions  frequently  contributes  to  the  favor- 
able economics  of  upsizing  that  protect  very  large  mainframes  from 
replacement  (see  Exhibit  VI- 1).  The  determination  of  whether  these 
aspects  of  network  management  should  be  (or  remain)  centralized  or 
decentralized  is  at  the  very  hean  of  developing  a  strategic  downsizing 
plan.  Most  of  the  case  study  companies  continue  to  wrestle  with  this 
problem  (or  problems),  but  one  thing  is  certain:  as  downsizing  proceeds 
the  complexity  of  network  management  increases  exponentially,  and  the 
need  for  network  management  tools  increases  accordingly. 

Dr.  Scherr  outlines  the  following  tools  that  may  be  necessary  to  maintain 
centralized  control  of  emerging  networks: 

•  A  data  distribution  and  collection  facility  that  would  schedule  and  track 
distribution  of  data  files  to  any  or  all  nodes  in  a  network.  (The  tool  must 
also  be  capable  of  collecting  data  files  from  the  network.) 

•  A  common  repository  for  user  configuration  profiles,  security,  and 
addressing  information  that  provides  uniform  access  to  data  on  a  net- 
work-wide basis. 

•  A  tool  that  allows  operational  personnel  to  monitor  and  control  multiple 
systems  without  having  to  see  individual  screens. 

•  "Programmed  operator"  support  that  reduces  the  need  for  human  inter- 
vention by  providing  preprogrammed  decisions.  (The  ultimate  objective 
being  "lights-out"  operation.) 
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•  Problem  determination  facilities  allowing  a  remote  "expert"  to  monitor 
the  usage  of  an  end  user  who  is  experiencing  difficulty  or  to  work 
directly  with  a  failing  system. 

Even  when  IS  management  is  convinced  that  all  applications  can  be 
downsized  to  more  cost-effective  platforms,  it  recognizes  that  the  systems 
software  necessary  to  manage  increasingly  complex  networks  is  currently 
available  only  on  mainframes.  That  is  the  reason  few  will  predict  when 
mainframes  will  disappear. 

c.  Predicting  Performance 

Predicting  network  performance  is  one  of  the  most  complex  problems  in 
developing  a  downsizing  plan.  Starting  with  the  first  implementation  of 
an  airline  reservation  system  (SABRE),  networks  have  had  a  disconcerting 
propensity  to  fail  unexpectedly.  On  individual  LANs  this  problem  has 
typically  been  solved  by  over-engineering  the  network,  but  data  sharing 
among  nodes  causes  unforeseen  problems. 

The  case  study  university,  which  has  been  on  the  leading  edge  of  network- 
ing technology,  found  this  out  when  bringing  up  a  relatively  simple  image 
processing  pilot  project.  Performance  of  the  overall  network  was  ad- 
versely impacted  because  of  the  traffic  through  a  particular  router.  Even 
after  upgrading  the  network  backbone  to  100  megabits  per  second,  and 
reconfiguring  Ethernet  to  minimize  the  number  of  hops  between  server 
and  client  end  points,  bulk  file  transfers  remain  a  continuing  problem  for 
other  users  of  the  network.  Current  router  technology  does  not  address 
application-specific  requirements,  and  per-application  priority  schemes  to 
allocate  bandwidth  require  dedication  of  specific  workstations  connected 
to  separate  networks — which  defeats  the  purpose  of  networking. 

Solving  these  problems  after  the  fact,  by  either  over-engineering  or  with 
new  systems  software,  obviously  alters  the  cost  justification  for  downsiz- 
ing. Therefore,  it  becomes  important  to  be  able  to  predict  network  perfor- 
mance before  the  fact. 

The  problems  of  predicting  network  performance  are  similar  to,  but  more 
complex  than  those  of  predicting  performance  of  large  mainframe  comput- 
ers operating  under  complex  operating  systems.  One  of  the  reasons 
INPUT  respects  Dr.  Scherr's  work  on  distributed  processing  is  because  he 
was  one  of  the  first  to  apply  queuing  network  theory  (as  developed  by 
operations  research)  to  predict  performance  of  central  server  networks 
(mainframes).  The  accuracy  of  the  results  employing  these  models 
startled  computer  scientists  at  first,  but  since  then  the  models  have  become 
widely  accepted  as  the  best  predictors  of  mainframe  performance. 
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While  progress  has  been  made  on  the  mathematics  to  extend  queuing 
network  theory  to  the  prediction  of  LAN  performance,  the  wide-area 
networks  required  by  extensive  use  of  the  client/server  architecture  remain 
an  unsolved  technical  problem. 

What  this  all  means  is  that  prediction  of  hardware  cost  savings,  when 
putting  together  a  downsizing  plan,  is  extremely  difficult — regardless  of 
how  attractive  those  processor  price/performance  ratios  may  appear.  This 
probably  explains  the  fact  that  respondents  to  INPUT'S  original  downsiz- 
ing survey  stated  that  the  primary  factor  prompting  downsizing  was  cost 
savings,  but  that  cost  savings  was  not  one  of  the  benefits  anticipated  from 
downsizing  projects  that  were  currently  close  to  completion.  [2]  It  also 
explains  why  responsible  IS  management  is  not  attempting  to  justify 
downsizing  on  the  basis  of  hardware  cost  savings  alone,  and  few  are 
willing  to  predict  when,  and  if,  their  mainframes  are  going  to  disappear. 

This  uncertainty  about  network  hardware  savings  and/or  mainframe 
replacement  carries  over  to  the  transition  costs  of  downsizing. 

P  

The  Transition  Trap 

Everyone  is  in  agreement  that  there  will  be  substantial  costs  associated 
with  any  major  architectural  transition  from  a  highly  centralized  main- 
frame environment  to  a  distributed  (downsized)  client/server  environment. 
Exhibit  VI-3  illustrates  the  factors  contributing  to  the  transition  trap. 

•  The  amounts  invested  in  downsizing  hardware  and  the  necessary  conver- 
sion effort  must  be  added  to  the  ongoing  cost  of  existing  hardware/ 
software  systems  until  those  systems  are  replaced.  Therefore,  the  total 
IS  cost  will  be  higher  during  the  transition  period. 

•  The  longer  the  transition  period,  the  higher  the  cumulative  "investment" 
in  downsizing  will  become.  It  is  of  the  utmost  importance  to  complete 
downsizing  efforts  as  expeditiously  as  possible  for  this  reason. 

•  There  are  several  unpleasant  facts  that  frequently  become  evident  during 
a  downsizing  transition  period: 

-  Downsizing  individual  applications  usually  does  not  result  in  immedi- 
ate, decreased  mainframe  expense.  While  it  can  be  demonstrated  that 
the  operating  expense  for  the  individual  downsized  application  is  less 
than  the  cost  would  have  been  to  run  it  on  the  mainframe,  the  total 
cost  to  the  organization  can  remain  higher.  (For  example,  the  mini- 
computer case  study  company  may  have  saved  a  specific  end  user 
$90,000  on  mainframe  billings  when  it  converted  some  applications  to 
its  UNIX-based  product  line,  but  the  expense  level  for  those  main- 
frames will  not  be  significantly  reduced  for  several  years.) 
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EXHIBIT  VI-3 


The  Transition  Trap 

Expense 

Total  IS  Costs  -^•^^"^"^'^'^ 

^^^^^^^..^^-^''''''''''^^—Cu^^  "Investment" 

Mainframe  IS  Costs  Savings" 

Downsizing  IS  Costs 

Time 

-  Where  an  actual  reduction  in  mainframe  expense  cannot  be  demon- 
strated, the  argument  is  frequently  made  that  mainframe  growth  has 
been  slowed  and  this  is  claimed  as  a  "savings."  This  type  of  "sav- 
ings" is  extremely  difficult  to  quantify,  and  it  seldom  falls  to  the 
bottom  line  where  management  can  see  it.  (Management  at  the 
railroad  wants  to  see  mainframe  software  expense  of  $3  million  go 
down,  and  it  will  not  be  impressed  with  arguments  that  additional 
investment  in  downsizing  technology  is  necessary  just  to  hold  the  line 
on  increasing  costs  of  software.) 

-  Downsizing  efforts  employing  new  hardware/software  technologies 
will  usually  suffer  from  the  traditional  problems  that  have  plagued  IS 
management — they  will  exceed  schedule  and  budget,  thus  prolonging 
the  downsizing  transition  period  and  expense.  (The  international 
energy  company  runs  the  risk  of  complicating  a  relatively  simple 
downsizing  effort  if  it  pursues  the  open  systems  option  and  introduces 
new  hardware/software  technology  during  the  transition  period.) 
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-  Downsizing  efforts  built  on  a  highly  centralized  model,  such  as  SNA, 
may  downsize -applications  and  distribute  data  only  to  find  that  cen- 
tralized network/data  base  management  may  require  mainframes  to 
grow  regardless  of  whether  they  continue  to  actually  process  any  end- 
user  applications  at  all  (It  is  probable  that  the  university  is  correct  in 
assuming  that  it  is  confronted  with  at  least  two  more  mainframe 
upgrades  regardless  of  how  rapidly  it  attempts  to  move  to  a  downsized 
client/server  environment.) 

Under  the  very  best  of  circumstances,  transition  periods  represent  a  time 
of  increased  information  systems  expense  with  the  distinct  possibility  that 
anticipated  hardware/software  savings  will  be  slow  to  materialize.  This 
represents  a  substantial  exposure  to  the  IS  department  that  justifies  down- 
sizing based  on  immediate  hardware/software  savings. 

That  is  why  IS  management  is  still  wrestling  with  the  well-known  chal- 
lenge of  justifying  investment  in  new  information  technology  based  on 
reduced  staffing  levels. 

E  

Downsizing  and  Staffing 

When  corporate  management  talks  about  downsizing,  it  really  means 
overall  reduced  staff  levels.  When  IS  management  jiistifies  information 
technology  based  on  improved  productivity,  it  really  means  reduced  user 
staff  levels.  One  of  the  primary  factors  prompting  downsizing  is  reduced 
IS  expense  for  applications  development  and  maintenance,  which  really 
means  reduced  IS  staff.  Downsizing  is  all  about  new  and  improved 
information  technology  replacing  white-collar  personnel  just  as  automa- 
tion replaced  workers  on  the  assembly  line  and  on  the  farm. 

While  there  is  some  ambivalence  on  the  part  of  IS  management  in  the 
strategic  case  study  companies  about  the  impact  of  downsizing,  there  is  no 
question  that  the  general  objective  of  downsizing  is  reduced  staffing 
levels.  (See  Exhibits  IV- 1  and  IV-3  to  IV-6.)  INPUT  has  several  observa- 
tions about  that: 

•  The  impact  of  personal  computers  on  white-collar  productivity  during 
the  1980s  was  neutral  at  best. 

•  Despite  the  enormous  investment  made  in  information  technology  to 
support  the  systems  development  and  maintenance  process  (hardware, 
applications  enabling  tools,  aids  and  methodologies,  etc.),  there  has  been 
no  demonstrable  improvement  in  overall  IS  productivity  over  the  last  30 
years. 
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•  The  availability  of  packaged  software  has  not  generally  reduced  the  size 
of  IS  staff  in  large  mainframe  installations. 

•  Any  discernible  improvement  in  white-collar  productivity  associated 
with  the  organizational  downsizing  of  the  1990s  seems  to  be  more 
related  to  longer  hours  for  the  remaining  white-collar  workers  rather 
than  to  the  use  of  information  technology. 

Is  there  something  magical  about  technological  downsizing  that  will 
suddenly  permit  the  improved  productivity  we  have  all  been  seeking  for  so 
many  years?  The  cases  studies  send  mixed  signals  in  that  regard. 

•  The  medium-sized  consumer  products  company  that  actually  eliminated 
an  IBM  mainframe  reduced  IS  headcount  by  30%,  and  yet  saw  salary 
expense  increase.  Though  INPUT  has  long  advocated  fewer,  more 
highly  skilled  personnel  as  a  means  of  improving  productivity  in  the 
systems  development  process,  it  doubts  that  management  anticipates 
increased  salary  expense  when  it  downsizes  headcount. 

•  The  railroad  has  periodically  reduced  IS  staff  by  transferring  data  entry 
and  quality  control  to  the  operating  department  (users),  only  to  centralize 
at  another  time  as  data  quality  problems  develop.  The  diffusion  of  such 
data  processing  functions  (and/or  responsibility)  to  user  personnel  is 
characteristic  of  the  distributed  processing  (client/server)  environment, 
and  every  indication  is  that  it  seldom  saves  the  company  money  but 
frequently  results  in  an  adverse  impact  on  information  systems  quality. 

•  Four  of  the  published  case  studies  mention  IS  staff  reductions  as  being 
one  of  the  benefits  of  downsizing  (Exhibit  V-1).  It  is  difficult  to  deter- 
mine how  much  actual  savings  accrued  to  these  organizations  as  a  result 
of  these  reductions,  since  transfer  of  data  processing  responsibilities  to 
clerical  personnel  in  operating  departments  frequently  results  in  upgrad- 
ing of  job  descriptions  because  such  personnel  now  must  be  "computer 
literate." 

We  can  only  conclude  that  there  will  not  be  a  magical  improvement  in 
white-collar  productivity  as  a  result  of  the  current  downsizing  trend.  It  is 
not  going  to  solve  all  of  the  IS  world's  historic  problems.  It  is  merely  the 
current  solution  to  continuing  problems  most  companies  have  faced  in 
making  effective  use  of  rapidly  changing  information  technology. 

However,  it  is  possible  to  reach  other,  more  important  conclusions  about 
downsizing  because  it  is  a  symptom  of  some  radical  changes  in  the  infor- 
mation technology  industry  and  in  management  mindset. 
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A  

Conclusions 

The  media  and  corporate  executives  would  like  to  believe  that  the  raw 
price/performance  advantages  of  new  processor  technologies  will  translate 
easily  and  direcdy  into  cost  savings.  The  long  history  of  improved  com- 
puter price/performance  indicates  that  this  has  seldom,  if  ever,  been  the 
case  where  commercial  applications  are  involved.  There  are  several 
reasons  for  this  and  practically  all  of  them  relate  to  software. 

•  Systems  and  applications  enabling  software  designed  to  make  computers 
easier  to  use  (specifically  IBM  operating  systems  and  data  base  manage- 
ment systems)  have  managed  to  consume  processing  cycles  at  least  as 
fast  as  mainframe  price/performance  has  improved. 

•  The  development  (or  conversion)  of  applications  systems  to  take  advan- 
tage of  the  latest  hardware/software  technologies  has  been  a  slow,  labor- 
intensive  process  that  extends  well  into  the  next  hardware  cycle. 

•  The  cost  of  systems  and  applications  enabling  software,  originally 
bundled  with  the  hardware,  has  increased  more  than  enough  to  compen- 
sate for  improved  hardware  price/performance. 

•  While  this  phenomenon  of  software  costs  absorbing  improved  hardware 
price/performance  has  been  especially  noticeable  on  mainframe  comput- 
ers, more  recent  experience  with  personal  computers  is  becoming  strik- 
ingly similar.  It  is  practically  as  if  some  mysterious  natural  law  is  at 
work. 

The  phenomenon  of  software  costs  absorbing  hardware  price/performance 
"savings"  before  they  ever  hit  the  customer's  pocket  is  no  longer  a  mys- 
tery to  IS  management — the  force  at  work  is  IBM.  IBM  systems  software 
is  the  driving  force  behind  the  demand  for  more  mainframe  processing 
power,  and  the  customer  is  now  paying  for  it  doubly — for  the  hardware 
necessary  to  run  the  software  and  for  the  software  itself. 
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Since  it  became  apparent  that  even  a  small  personal  computer  had  enough 
raw  power  to  process  many  commercial  applications,  even  IBM  had  to 
come  up  with  its  own  "downsizing"  plan.  That  plan  was  (and  perhaps  still 
is)  SAA.  IBM's  inability  (or  unwillingness)  to  explain  (sell)  and  imple- 
ment that  plan  in  a  timely  manner  has  created  confusion,  and  even  resent- 
ment, among  the  IBM  customer  base.  This,  in  turn,  has  resulted  in  a 
significant  loss  of  IBM  account  control. 

IS  management  is  actively  pursuing  downsizing  and  new  application 
architectures  (specifically,  client/server)  independent  of  SAA.  However, 
while  traditional  IBM  account  control  has  suffered  considerably  during  the 
last  ten  years,  IBM  customers  now  find  themselves  trapped  on  large 
mainframes  by  existing  systems  and  applications  software— to  say  nothing 
of  those  large  centralized  data  bases.  In  order  to  achieve  the  immediate 
cost  savings  desired  by  management,  mainframes  must  be  replaced  be- 
cause merely  moving  applications  code  does  not  lower  the  cost  of  large 
mainframes  appreciably. 

The  low  end  of  the  IBM  mainframe  line  of  computers  has  been  vulnerable 
to  cost-effective  replacement  through  both  upsizing  and  downsizing  for 
several  decades. 

•  Traditional  economy  of  scale  still  exists  in  the  IBM  mainframe  product 
line,  but  the  most  significant  cost  savings  associated  with  upsizing  from 
small  mainframes  are  to  be  found  through  centralization  of  human 
resources  necessary  for  systems,  network,  and  data  base  support  and 
management. 

•  The  raw  price/performance  advantages  of  minicomputers,  RISC  proces- 
sors, and  personal  computers  have  been  well  publicized;  however,  the 
primary  cost  benefits  of  downsizing  will  come  from  the  eUmination  of 
complex  and  expensive  systems  and  apphcations  enabling  software  on 
mainframes. 

Only  low-end  mainframes  are  currently  being  replaced  by  downsizing,  and 
IS  management  does  not  see  any  easy  way  to  replace  high-end  mainframes 
in  the  foreseeable  future.  In  fact,  it  is  probable  that  installed  mainframes 
will  continue  to  grow  during  the  early  phases  of  transition  to  a  client/ 
server  architecture.  The  specific  problems  associated  with  replacing  larger 
mainframes  are: 

•  The  enormous  effort  required  to  convert  existing  mainframe  COBOL 
applications 

-  Technical  problems  associated  with  maintaining  data  and  program 
quality  (integrity,  synchronization  and  security)  in  a  distributed 
environment 


VII-2 


©  1992  by  INPUT.  Reprodudion  Prohibited. 


UIDCS 


CASE  STUDIES  IN  DOWNSIZING 


INPUT 


•  The  simple  fact  that  large  mainframes  remain  the  only  effective  solution 
for  a  certain  class  of  commercial  applications  with  a  high  degree  of  data 
sharing 

However,  there  is  substantial  pressure  from  corporate  executives  to 
downsize,  and  IS  management  recognizes  that  more  cost-effective  solu- 
tions are  available  for  some  mainframe  applications.  While  corporate 
executives  may  be  reacting  to  media  hype,  most  IS  managers  are  willing 
to  concede  that — given  a  clean  slate — many  mainframe  applications  could 
be  more  cost  effectively  implemented  on  downsized  platforms. 

Unfortunately  the  IS  department  doesn't  have  a  clean  slate,  and  downsiz- 
ing individual  applications  will  not  normally  achieve  the  savings  desired 
by  management.  Mainframe  hardware/software  expense  just  doesn't  scale 
down  in  direct  proportion  to  the  applications  that  are  offloaded. 

In  addition,  the  promise  of  off-the-shelf  applications  software  for  major 
commercial  applications  remains  pretty  much  a  dream  for  large  organiza- 
tions. Even  when  downsizing  has  actually  resulted  in  small  mainframes 
being  replaced,  it  has  been  found  that  conversion  (transition)  costs  are 
substantial;  and  when  going  to  an  open  environment,  adding  necessary 
skills  in  UNIX  and  C  tends  to  inflate  transition  costs  even  further. 

IS  management  is  being  placed  in  the  difficult  position  of  appearing  to 
resist  downsizing  whenever  it  identifies  problems  associated  with  the 
radical  changes  of  information  architecture  that  are  being  proposed. 
However,  responsible  IS  management  must  insist  on  detailed  cost/benefit 
analysis  if  unpleasant  surprises  are  to  be  avoided. 

The  most  likely  unpleasant  surprise  is  an  extended  and  expensive  transi- 
tion period  during  which  dual  hardware/software  systems  remain  installed. 
Once  the  decision  to  downsize  is  reached,  it  is  extremely  important  to  get 
through  the  transition  period  as  quickly  as  possible,  especially  if  the 
objective  is  to  replace  the  entire  mainframe  (as  opposed  to  downsizing 
only  specific  applications). 

The  need  to  have  tight  transition  schedules  makes  the  methodology  and 
tools  employed  for  downsizing  critical.  That  is  the  reason  that  Methodolo- 
gies for  IT  Downsizing  will  be  the  next  INPUT  report  in  this  series.  How- 
ever, even  with  the  best  tools  available,  conversion  of  major  mainframe 
applications  to  client/server  architecture  can  be  a  daunting  and  high-risk 
task — enough  so  that  one  has  to  question  the  advisability  of  downsizing 
for  downsizing' s  sake  where  the  primary  cost  justification  is  based  on 
potential  reduction  in  hardware  or  IS  costs. 
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INPUT  concludes  that  the  proper  justification  for  IT  downsizing  must  be 
directly  related  to  the  contribution  the  new  information  architecture  can 
make  to  business  objectives.  Since  business  objectives  for  most  compa- 
nies these  days  depend  upon  improved  productivity  of  white-collar  work- 
ers at  all  levels  in  the  organization,  the  primary  cost  justification  for 
downsizing  should  be  the  reduction  of  end-user  staff  through  improved 
work  processes.  This  impHes  significant  re-engineering  of  current  main- 
frame applications. 

It  is  input's  conclusion  that  such  re-engineering  can  be  most  effectively 
performed  by  in-house  personnel  (regardless  of  organizational  location). 
Since  maintenance  of  existing  systems  consumes  such  a  high  percentage 
of  IS  resources,  the  question  becomes  one  of  being  able  to  free  up  the 
necessary  resources  to  implement  the  downsizing  project  on  a  timely 
basis.  Most  companies  will  probably  require  the  use  of  outside  services  in 
order  to  isolate  the  downsizing  conversion  team  from  routine  maintenance 
of  existing  mainframe  systems. 

The  relatively  high  fixed  expense  of  current  mainframe  hardware/software 
as  downsizing  proceeds  can  also  absorb  financial  resources  necessary  for 
timely  implementation  of  the  downsizing  effort.  It  is  imperative  to  find 
some  way  to  receive  immediate  mainframe  cost  savings  as  applications  are 
moved  to  the  client/server  environment.  Outsourcing  may  be  attractive  in 
reducing  mainframe  cost  on  a  timely  basis. 

The  current  highly  centralized  information  architecture  associated  with 
mainframe  systems  is  based  on  the  belief  that  extensive  data  sharing 
among  users,  applications  and  data  bases  is  a  fact  of  life  in  the  commercial 
environment.  Therefore,  complex  and  expensive  systems  software  is 
required  to  manage  the  corporate  data  bases,  and  comprehensive  distrib- 
uted data  base  management  is  projected  to  be  a  universal  requirement  as 
downsizing  (and  SAA)  proceeds.  Acceptance  of  this  hypothesis  (which  is 
essentially  IBM's)  gives  eternal  life  to  the  mainframe  superserver  in  most 
organizations,  and  it  should  be  questioned  by  responsible  IS  management. 

INPUT  concludes  that  a  significant  number  of  mainframe  applications  can 
be  downsized  and  converted  to  client/server  using  simple  pair-wise  con- 
nectivity and  file  transfer.  This  being  the  case,  the  primary  technological 
battle  at  the  server  level  as  downsizing  proceeds  will  be  between  UNIX 
and  the  proprietary  OS/400.  PC  LANs  and  routers  have  a  role  to  play,  but 
they  will  seldom  be  able  to  break  free  from  some  type  of  mainframe 
control  when  major  applications  are  being  downsized. 

Uncoordinated  top-down  downsizing  of  mainframe  applications  and 
uncontrolled  bottom-up  upsizing  of  personal  computer  applications  to  the 
client/server  environment  have  high  potential  for  severe  integration  prob- 
lems and  even  chaos.  An  overall  long-range  plan  or  information  architec- 
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ture  is  essential — regardless  of  whether  the  IS  function  is  centralized, 
decentralized  or  abolished.  Failure  to  develop  such  a  plan,  and  make 
provision  for  control  during  transition,  can  militate  against  achieving  the 
potential  benefits  of  any  new  information  architecture. 

To  the  degree  that  large  mainframes  remain  as  super  data  base  servers,  it 
will  be  necessary  to  place  some  value  on  the  centralized  data  bases  that 
support  the  applications  work  being  done  at  the  working  level.  It  is 
anticipated  that  the  cost  of  data  manipulation  and  management  on  large, 
general-purpose  mainframes  will  be  sufficiently  high  to  speed  the  devel- 
opment and  use  of  a  new  class  of  more  specialized  data  base  machines. 

B  ^  

Recommendations 

Consider  downsizing  as  a  part  of  overall  network  and  data  base  manage- 
ment, and  begin  by  analyzing  the  data  and  information  flow  of  the  organi- 
zation. Scherr's  work,  briefly  cited  in  this  report,  can  be  a  good  place  to 
start  in  conducting  such  analysis  (it  will  be  reviewed  in  more  detail  in 
input's  report.  Methodologies  for  IT  Downsizing). 

Before  proceeding  with  downsizing,  do  a  thorough  cost/benefit  analysis  of 
current  mainframe  systems,  with  special  emphasis  on  the  value  of  corpo- 
rate (or  large  mainframe)  data  bases.  The  cost  factor  matrix  supplied  in 
this  report  is  a  good  place  to  start,  and  it  should  be  used  and  refined  as 
downsizing  plans  are  developed  and  implemented. 

Though  it  is  assumed  that  most  organizations  are  (or  will  become)  familiar 
with  advanced  personal  computer  operating  systems  (OS/2  2.0,  NT,  etc.), 
IS  management  should  also  become  familiar  with  the  relative  strengths 
and  weaknesses  of  UNIX-based  and  AS/400  servers  as  downsizing  plat- 
forms for  mainframe  applications.  It  is  anticipated  that  proprietary  and 
open  systems  will  coexist  in  most  downsized  networks,  and  the  education 
and  training  of  systems  personnel  should  begin  as  soon  as  possible. 

View  any  small  mainframe  systems  as  good  candidates  for  replacement 
either  by  downsizing,  upsizing  or  outsourcing.  There  is  seldom  justifica- 
tion for  having  such  systems  installed. 

Identify  and  analyze  mainframe  single-application  (or  limited  data  shar- 
ing) systems  as  potential  candidates  for  re-engineering  and/or  downsizing. 
Such  dedicated  mainframe  systems,  of  any  size,  are  costly  because  of 
mainframe  systems  software  expense,  and  are  usually  easier  to  downsize 
than  applications  with  complex  data  interdependencies.  They  are  prime 
candidates  for  downsizing. 
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Carefully  evaluate  the  availability  of  packaged  software  for  the  downsized 
application.  The  potential  for  savings  is  great,  but  so  is  the  potential  for 
failure  if  the  packaged  software  requires  companies  to  change  their  prob- 
lem to  fit  the  packaged  solution. 

Consider  the  possibility  of  shifting  maintenance  of  existing  mainframe 
systems  to  an  outside  services  organization  in  order  to  free  up  internal 
systems  personnel  for  the  downsizing  and/or  re-engineering  effort.  As  the 
information  architecture  becomes  more  in  line  with  business  needs,  it  is 
highly  desirable  to  have  knowledgeable  internal  personnel  responsible  for 
development,  installation  and  maintenance. 

Consider,  and  carefully  evaluate,  the  possibility  of  outsourcing  mainframe 
operations  that  are  selected  for  downsizing.  Any  such  outsourcing  con- 
tract should  have  provision  for  scalable  costs  as  individual  applications  are 
downsized.  Outsourcing  is  a  good  way  to  establish  benchmarks  for 
downsizing  applications  and  also  for  placing  a  value  on  centralized  data 
bases. 

Ensure  that  there  is  broad  management  acceptance  and  responsibility  for 
the  planning,  implementation,  and  management  of  the  resulting  informa- 
tion architecture.  If  downsizing  is  approached  with  an  "us"  and  "them" 
attitude  on  the  part  of  either  IS  or  the  user  community,  it  will  be  doomed 
to  failure.  Properly  organized  and  managed,  the  downsizing  effort  can 
serve  as  a  catalyst  for  the  effective  use  of  information  technology  to 
support  business  objectives;  current  mainframe  systems  clearly  demon- 
strate that  this  is  too  important  an  issue  to  be  entrusted  to  any  vendor. 
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